QNX is a microkernel-based real time operating system. The kernel is tiny; it was about 60KB (not MB) twenty years ago. All the kernel does is message passing, timers, CPU dispatching, and memory allocation. Everything else is in user space, including file systems.

Everything is a message, rather than being a file. Messaging works like a function call - you send a block of data to another process, wait, and get a reply back. Processes which receive messages act like servers - they have a thread or threads waiting for incoming requests, and when a request comes in, it's handled and a reply is sent back. It's a microservices architecture.

Unlike Linux, it's a fast microservices architecture. Message passing and CPU dispatching are integrated. When a process sends a message to a service process, the sender blocks. (Timeouts are available.) If the service process isn't busy, control immediately transfers to the service process without a trip through the CPU dispatcher. When the service process replies, the reverse happens, and control goes back to the original sender. With most inter-process communication systems, there's queuing delay for this kind of operation. QNX got this right. This is the core insight behind QNX.

Yes, there is message passing copying overhead. In practice it's under 10%. I've sent video through the message system. Copying is less of a problem than you might expect, because, with today's large CPU caches, the data being copied is probably warm and in cache.

All this is real-time aware. Higher priority processes get their messages through first. If you call a service, it inherits the caller's priority until it replies. This prevents priority inversion, where a high priority process calls a low priority one and gets preempted by lower priority work. This works so well that I was able to do compiles and web browsing on a single-CPU machine that was also running a robot vehicle.

There's a tool for building boot images. You put in the kernel, a standard utility process called "proc", and whatever else you need available at startup. For deeply embedded systems, the application might go in the boot image. It's all read-only and can execute from ROM if needed, which is good for applications where you really, really want startup to always work.

Files and file systems are optional. For systems with files, there are file system and disk drivers to put in the boot image. They run in user space. There's a standard startup program set that creates a Unix-type environment at boot time. This is all done in user space. The file system is accessed by message passing.

System calls look like POSIX. Most of them are implemented in a library, not the kernel. Service processes do the work. When an application calls POSIX "read", the library makes an interprocess function call to the file system or network service server. Program loading ("exec") is done in user space. The boot image can contain .so files. "Exec" is done by a .so file that loads the image. So the kernel doesn't have to worry about executable format, and program loading is done by untrusted code.

Because it uses POSIX, most command line UNIX and Linux programs will compile and run. That's QNX's big advantage over L4. L4 is a good microkernel, but it's so stripped down it's just a hypervisor. Typically, people run Linux on top of L4, so all the bloat comes back.

There is no paging at the OS level. That would kill real-time. There's a paging to disk library that can be used by programs such as compilers with big transient memory needs, but most programs don't use it. The effect is that responsiveness is very consistent. I miss using QNX desktop. There's no lag.

So that's an overview. Microkernel done right.

I mean, I figured it out from HN but still.