Teaser : Linux to take off

Well, fairly aggressive this title is... But by 'takeoff' I mean... embedded in planes ! For yes, one major project has emerged whose aim is to provide tools to ease DO-178 certification. Plus another project to be announced clearly aims at providing an allegedly restricted but nevertheless hard real time kernel based on Linux.

What real work is not yet done to date ? In my opinion, not much for the description, but this shortly described work means much, a big tedious but careful job to begin.

The remaining areas of concern ?

Well, as most drivers are probably following the good practise guidelines implementing interrupt handlers in 2 parts (either task queue or bottom half), a few probably remain. Targetting DO certification, only certified hardware will be of concern though. To aim at making a fully featured RT kernel, the drivers for non-certified hardware will need expertise, and some of the job might be done in the meantime.

The scheduler does have a superseded O(1) algorithm. The new algorithm, actually diverging at O(ln(n)), is however much faster than the O(1) for all real-life cases (less than 4G processus). Again, no concern here.

The malloc will need careful audit, then. This will be tedious but I am confident, as Linux use has already spread so that I am sure the audit is already fairly advanced.

Next idea lies where all the error and exceptions handling functions are. These are the other possibility of undesirable unbounded latency.

Then what ? After all the work in between have been considrerd, I think we are then almost done. Provided no-one uses the Joystick port any longer (that one can only be driver via active wait), we have then dealt with all things a processus and drivers can do : syscalls, memory, read/write, interrupts, errors...

The project in which all this work will be issued is to be announced shortly...

OpenBSD's bleeding edge pf

Even though I am no networks specialist, I have been involved in the business of having to understant how OpenBSD's packetfilter, aka pf, does round-robin load balancing.

The why of this expertise was quite straightforward : as pf does round-robin exactly well and balances the load exactly as expected, the first ever target, I mean the first target when the rules are set, has been found not to be the first in the list. This remark possibly matters 0.001% of all potential pf users, but I have then been required to check pf's predictability - an unpredictable pf's first was the most seriously fact feared...

This holds for OpenBSD 4.2, ie a fairly old one, but pf code has hardly changed since, and I have not seen any change in the lines involved here.

What happens is that, using BSD's TAILQ structures and macros, pf does choose the first in the list, then iterates before selecting the target. In a word, the first target that the load balancing hits is the second in the list. It is fully predictable and safe : a behaviour well in OpenBSD's tradition.

In the end, I had to patch the program that generated our pf rules, so the first does come first in the production system...