Archive for the 'Hardware' Category

Let’s talk micro kernels

Thursday, February 14th, 2019

Over four years ago I wrote about Why monolithic kernels are fail and last night I live streamed some talk about micro kernels:

And in my famous prior art patent voiding serious I wanted to formerly disclose a potentially novel system call implementation detail idea: In multi server micro kernels context switches happen more frequent than in simple, shared address space monolithic kernel (such as Linux). This is due to device drivers (and filesystem, network stacks and hopefully everything else, ..!) hopefully running in regular, isolated processes. This is obviously great for security and stability, but naturally requires way more context switches that can hurt performance. Now slim and lightweight micro kernels (such as L4) are usually quite optimized and often require less instruction cycles for inter address space context switches, however such a horde of multiple servers will execute multiple times more of those. Now my (novel?) idea to further minimize the costs of context switches is to bundle system calls in batches (or molecules? ;-) so that an application (or device driver, after all they should now be regular processes, …!) only context switch once for a couple of system calls. The exact ABI calling convention and format has to be defined by the implementor and implementation, for simplicity let’s assume some kind of “protocol buffer”, so a open, read, seek, read sequence could look like:

syscallnr | arg0 | arg1 | arg2 | …
read | fd | buffer | 128
seek | fd | -128 | SEEK_END
read | fd | buffer | 128

The same concept obviously applies to all kind of similar operations, and is somewhat similar to the existing Unix concept of writev(), and it’s iovec structure – just way more generic and flexible.

As a bonus point for more flexibility, one could either implement it so, that the syscalls are executed one-by-one until the first error, or optional –for a little more flexibility– introduce flags / tags of groups to execute until and error occurs or not. E.g. the operations might be related to two different file descriptors, so the other tagged group could still be executed, even when one of them failed. Obviously error checking for the calling application becomes a multi return value operations, instead of just a single if (!read/write/…) {} block.

Still searching for the perfect laptop…

Monday, January 14th, 2019

Over a decade, 12 years (!!!) ago I wrote about who designs this crap (this millenniums laptops). And here we are the Apple MacBooks became even more unusable, with soldered in RAM, SSD, really crappy keyboards, that get stuck by mere dust. And while I would love a nice generic quality PC, there is always something wrong with each and every model. Thermal throttling, crappy keyboards, too. You name it. It is no wonder that PC sales are declining when users can not find a good and matching device:

Linux on macOS w/ Xhyve & Hypervisor.framework

Saturday, December 8th, 2018

Just the usual quite note for myself ;-)

xhyve -A -m 512m -c2 -f kexec,~/Downloads/boot64/vmlinuz_4.19.4-dist,initrd2,”earlyprintk=serial console=ttyS0 root=/dev/vda1″ -s 0:0,hostbridge -s 31,lpc -l com1,stdio -s 2,virtio-blk,~/Downloads/linux-vm.img -s 4:0,virtio-net -s 5,fbuf,tcp=,w=1024,h=768


Sunday, October 7th, 2018

I thought we went from SATA connected (to AHCI board controllers) straight to PCIe connected NVMe protocol. Turns out there was a short time of PCIE connected SSDs with an AHCI controller. And of course Apple used them:

One can never have enough dongles^W proprietary connectors to lock users out, ..! :-/

Finally the first AMD ThinkPad!

Friday, September 21st, 2018

For decades fans of AMD, the inventor of x86-64, GPU infused APUs, and avoiders of a 100% Intel x86 monopoly where longing for a really high end quality machines, like IBM^W Lenovo ThinkPads. The dream came finally true, with AMD Ryzen w/ Vega gfx ThinkPads A285 and A485 this year.

This is a developing story, we will update with a review in a day or two.

Resist NVidia, especially for Linux

Friday, September 7th, 2018

So I do Linux kernel, driver, libraries, gcc, development since 1998. A little bit everywhere, all over the place. X86, ARM, PowerPC, SPARC you name it. I contributed to the Linux distribution ROCK Linux, later became stable release maintainer, and still run the fork #t2sde for embedded and special custom Linux distributions. My company ExactCODE was involved in many embedded projects and development like that, and in 2008 a customer wanted to base a product on the Nvidia Tega SoC, so I wrote Nvidia if they could release us any register level spec, even under NDA, to work on such a project. To my surprise I got an answer, but it was a simple one-liner, and not really what we needed to hear:

How is your Windows CE experience? We are not supporting Linux on Tegra.

Received: from (Not Verified[]) by
id ; Tue, 22 Jul 2008 12:56:40 -0700
Subject: RE: NVidia SoC SPECs for Embedded Linux systems
Date: Tue, 22 Jul 2008 12:57:03 -0700

How is your Windows CE experience? We are not supporting Linux on Tegra.

—–Original Message—–

For the currently engaging projects we need solid 3D support in
our portfolio we would kindly ask for the possibility to sign an NDA
to receive register level specs support NVidia’s latest integrated
embedded SoC’s in our boards support offerings.

Just for those why I can not, and will never recommend chips without register level data sheets available to developer, ..!

20 years, and over 400 scanner drivers

Friday, August 24th, 2018

Quite exactly 20 years ago I purchased my first scanner, after saving for years for my first computer: A Pentium 120, at first even running with our old ISA VGA card from my farther’s ageing 386sx25. Lafter, after saving more for my first VGA card, an ELSA Victory 3D w/ S3/Virge3D, it was also time for the first peripherals and of course to get analog material into the digital world I needed a scanner: a c’t mgazine well rated AVision AV630CS. But as Windows crashed too often than not on me, it was also time to migrate to Linux. Remember that was 1998 when few actually heard about it. And of course I had to write my own SANE scanner driver - and the rest is history:

Bluetooth apt-X finally works w/ OpenSource!

Wednesday, June 6th, 2018

I also finally hcidump’ed which codecs my Sennheiser Momentum 2.0 supports, as the marketing material is often not that detailed and trustworthy. So besides the standard SBC; only apt-X:

# hcidump | grep -i codec
Media Codec - non-A2DP (aptX)
Media Codec - SBC
Media Codec - non-A2DP (aptX)

CLI, manual Bluez connection

Monday, June 4th, 2018

# bluetoothctl

power on
agent on
scan on
pair xx:…
connect xx:…

Notes. installing Irix, Octane, O2

Saturday, April 21st, 2018

Empty HD:

boot -f dksc(1,3,8)sash64
# boot -f dksc(1,3,8)sashARCS

boot -f dksc(1,3,7)stand/fx.64 –x
# boot -f dksc(1,3,7)stand/fx.ARCS –x

Install System Software

2 to open media
# insert all CDs

then to install:

keep *
install standard

in case of conflicts:

conflict 1a 2a .. .. ..

Obviously, more detailed tips at the usual:, …