Vivian Voss

Discipline Without Descent

qnx microkernel rtos posix

Last Monday closed on the BSDs, four forks off one Berkeley source that stayed whole, and it pointed here, to an outsider with none of the blood. QNX is not descended from Unix. No line of it runs back to Bell Labs or to Berkeley; its kernel was written from nothing by two students who had taken a course and formed an opinion. And yet it keeps the rules Unix wrote more strictly than several systems that hold the certificate, which is the puzzle worth explaining: how a family's discipline comes to be inherited by someone outside the family.

Begin with the name, since the name tells the story in miniature. In 1980 Gordon Bell and Dan Dodge, fresh from a real-time operating-systems course at the University of Waterloo, started a company in Kanata, Ontario, and in 1982 shipped their first system for the Intel 8088. They called it QUNIX. Two years later they renamed it QNX, to keep clear of the Unix trademark. The edit is the whole thesis in miniature: a system close enough to Unix in spirit to want the syllable, and honest enough not to claim the descent it did not have.

If you want the discipline made physical, the 1999 demo disk is the artefact. Quantum put an entire graphical operating system onto a single 1.44-megabyte floppy: a windowing system, a TCP/IP stack, a file manager, a handful of small applications, and a web browser that rendered real pages, all self-booting on a machine with no hard drive and eight megabytes of memory. The image was downloaded well over a million times, which for a firm that did not otherwise advertise was not a small return. One could read the floppy as a stunt. It is more useful read as a proof of what the discipline buys, since a browser and an operating system do not fit into that space by luck, and they certainly do not get there assembled from a hundred other people's parts.

The Rules Without the Blood

It helps to say plainly what the discipline is, because the word gets used loosely. Unix discipline is a small set of load-bearing habits: build the system from small parts that each do one thing; keep a clean line between what a component promises and how it works; prefer text and simple interfaces a person can inspect; and hold to the POSIX contract, the published specification of what a Unix-shaped system does when a program asks it for something. None of that requires the original source code, and none of it requires membership.

QNX shows the separation with unusual precision, having gone and got the certificate for the rules while holding none of the certificate for the family. Its Neutrino kernel is certified to the POSIX PSE52 realtime profile, IEEE 1003.13-2003, under the conformance programme the IEEE and The Open Group run together, and it implements several hundred further POSIX interfaces besides. The paper it carries is a paper about behaviour, that the system does what a POSIX system is specified to do. It is not the Single UNIX Specification certificate the first Monday of this series described, the one that lets a vendor print the word UNIX in capitals; QNX has never claimed it, having no claim to make. Here, then, is a family member, if the word still means anything, carrying a certificate for the conduct and none for the bloodline. The rules were the inheritable part all along.

A distinction keeps this from meaning anything with a POSIX layer bolted on. Plenty of systems have offered POSIX for compatibility, so that Unix software would compile against them, without being built to the discipline underneath; BeOS did exactly that, and so, for a stretch, did Windows NT. Offering the rules as a courtesy to visiting software is a lesser thing than keeping them as the design, and that lesser story is one for another Monday. QNX kept them as the design.

The Microkernel Choice

The kernel is where the outsider stops resembling its cousins and starts, in one respect, outdoing them. Traditional Unix, and Linux after it, runs a great deal inside the kernel: the drivers, the filesystems, the network stack, the scheduler, all in one privileged address space, because putting them there is fast and was, for decades, simply how it was done. QNX made the choice Unix declined to make. Its microkernel keeps only the few things that genuinely cannot live elsewhere, the scheduler, interrupt handling, low-level memory, and the message-passing by which everything talks, and it turns the rest out into ordinary user-space processes.

Where the operating system runs Monolithic kernel one privileged address space scheduler drivers filesystems network stack a fault in any one can take the whole down QNX microkernel kernel: scheduling, IPC, interrupts, memory driver filesystem network stack the rest are user-space processes A driver becomes a program you can kill and restart.

Put that concretely, since it sounds abstract and is nothing of the kind. On QNX a disk driver is an ordinary program with no special privileges, and the filesystem and the whole TCP/IP stack are the same, each one reached by sending it a message and waiting for the reply. The arrangement reads like the Unix philosophy taken at its word and then turned on the kernel itself, which is the one place Unix had declined to apply it. And it pays in the currency that matters at three in the morning: a driver on a monolithic system that corrupts memory it does not own takes the system down with it, whereas on QNX the same misbehaving driver is a process you can kill and restart while everything else keeps running, debugged with the ordinary gdb you would point at any other program. The line Unix draws between programs, QNX draws between the parts of the operating system, one level down.

There is a second dividend, and it explains why the aerospace and medical engineers were interested long before the carmakers were. A kernel that small, doing that little, can be reasoned about, and a system whose response time can be bounded can be certified. Real-time determinism, the guarantee that a thing happens inside a fixed and provable window, falls out of the same design that gives the fault isolation. You do not reach it by tuning a large kernel. You reach it by not having one.

The Code It Borrowed

Discipline and pride are different things, and QNX is refreshingly short of the second. When it wanted a modern network stack it did not sit down to reinvent one for the pleasure of having written it. The io-pkt stack was built to follow the NetBSD networking code and architecture as closely as it reasonably could, so that a NetBSD driver ports across with little drama and a program written to the BSD sockets interface finds itself at home. That is the NetBSD from last Monday, the sibling whose entire personality was portability, lending its network code to a system outside the family altogether.

It is worth a moment on how in character that is for both parties. NetBSD wrote a stack meant to travel; QNX, needing one, took the well-travelled stack over a homemade one. The purist reading, that a true original writes everything itself, has the discipline backwards. The Unix tradition was always one of reuse, of small good parts composed rather than rebuilt, and adopting a proven stack rather than nursing a new one into correctness observes that tradition rather than breaking it. Part of how QNX kept the rules was in knowing which code it did not need to own.

Where It Lives

All of this would be a curiosity had it stayed on the floppy, and it did not. QNX went where a crash counts as an incident rather than an inconvenience: industrial controllers, medical devices, the surgical robot, the reactor monitor, and above all the car. BlackBerry, which bought QNX in 2010, reports it running in well over a hundred million vehicles, and in December 2019 its hypervisor became the first commercial hypervisor certified to ISO 26262 ASIL D, the highest automotive safety-integrity level, by TÜV Rheinland. The instrument cluster that must draw your speed correctly every time, and the domain controller charged with keeping the entertainment system's failures away from the brakes, are as often as not sitting on it.

The honest question is why QNX rather than Linux, since Linux is in cars too, and the answer owes nothing to marketing. It is the microkernel once more, read from the buyer's side. Where the requirement is a bounded response time you can prove, and a fault in one component that cannot reach another, and a certification body willing to put its name to both, a small kernel with the drivers held outside it becomes the short path to that signature, aesthetics quite beside the point. Linux runs the dashboard you tap; the layer that must not fail while you are doing seventy on the motorway tends to be the outsider with no Unix blood in it.

The Others Who Kept the Rules

QNX is the most successful instance of the pattern, and it is not the only one; the company it keeps is instructive. MINIX, which Andrew Tanenbaum wrote in 1987 to teach the subject and to prove that a working operating system need not run to millions of lines, is a microkernel of the same conviction, its drivers in user space and a dedicated server whose whole task is to notice a dead one and restart it. It also holds the strangest deployment record in the field, since a version of it has run since about 2015 inside the management engine of essentially every Intel processor, which makes a teaching system, on one accounting, the most widely installed operating system nobody ever chose to install. GNU's Hurd set out in 1990 to be precisely this, a POSIX system on a microkernel, and remains the cautionary member of the class, the ambition intact and the 1.0 release still, a Stallman promise of 2002 notwithstanding, unshipped. Redox carries the argument into the present, a Unix-like microkernel written from scratch in Rust since 2015, its drivers outside the kernel and whole classes of memory bug designed out of the language beneath, the rules kept and the blood once more entirely absent. QNX is not alone in its commercial niche either, where real-time systems such as LynxOS and VxWorks have kept a POSIX face over hard deadlines for decades.

Same conviction, different fortunes QNX shipped; runs in 100M+ vehicles, first ISO 26262 ASIL D hypervisor MINIX (1987) a teaching microkernel, and quietly inside nearly every Intel chip GNU Hurd (1990) the ambition intact, the 1.0 release still unshipped Redox (2015) the same idea in Rust, drivers outside the kernel The rules kept, the blood absent, the fortunes far apart.

The Point

The family portrait so far has hung on two kinds of belonging, the certificate and the bloodline, and QNX has neither in the sense the first two Mondays meant. It holds the discipline more faithfully than some who have both, which is not the ranking anyone drawing the family tree would have predicted, and which forces the axes apart. Descent is a matter of where the code came from. The paper measures the behaviour against a specification and says who checked. Discipline is a third thing again, the way a system is built and kept over time, and it is the only one of the three a stranger can pick up by deciding to, as two students in Ontario did with a course behind them and nobody's permission.

Three kinds of belonging, and where QNX stands Descent the code lineage, back to Bell Labs or Berkeley none The paper the certificate, and who measured it POSIX, not UNIX Discipline the living practice of how a system is built and kept stricter than most Only discipline can be adopted from outside the family.

That leaves the largest member of all, the one that took the resemblance and the reach and went somewhere the discipline did not follow.

Next Monday: the most successful system in the world, and how far it drifted.