[heja2009]

I worked with QNX 4 at uni and we built a robot system based on 2-4 networked 486/Pentium CPU cards in a rack with it [1]. We fully used the OS to make our robot system both hard real-time and completely network based using QNX's native capabilities. This gave me a deep understanding of those issues in my later career in robotics systems and I basically recreated - tediously - most of its features with UDP, TCP/IP and various IPC (inter process communication) features on vxWorks, SunOS and Linux.

One feature of the OS I fondly remember was that the most basic system calls (send/receive/reply) were implemented as about 3 inline assembler instructions each directly in the header file (qnx.h ?).

[1] https://herbert-janssen.de/paper/irini97-12.pdf

[pjmlp]

QNX used to be the golden standard of impossible things for microkernels, that in reality are actually used.

Nowadays not sure how it compares to other ones with wide field experience like Nintendo Switch Horizon, seL4 and more recently HarmonyOS NEXT.

[Rochus]

The HongMeng kernel, performance wise, seems indeed to be in the same ballpark as sel4 or QNX, but it doesn't seem that it will be open-sourced.

[vacuity]

Perhaps it won't be open sourced, but having read one of the papers written for it, the principles behind its advancements can easily be added to the microkernel repertoire.

[Rochus]

What's the core concept compared to other kernels?

[vacuity]

At its core, it's not too distinct from, say, seL4, but some of the distinctions are useful. I think Hongmeng's work on isolation classes (particularly in transferring components across classes), a performance-motivated partial alternative to capabilities, OS service coalescing and partitioning, and porting Linux drivers are valuable (see sections 4.2-4.4 and 5 [0]). It's not that these changes should be accepted wholesale, but I think they are a useful data point for alternate designs. I think the emphasis on access control (capability) performance and driver coverage are relevant for any production-grade microkernel.

I don't like the paging optimization described in section 4.5 [0]. It seems like a lot of added complexity for unequal gain.

In general, the authors make many good observations on the current designs of microkernels, particularly how the proliferation of small processes harms performance. Based on my reading of this paper and many others, I think there are some pragmatic considerations for building microkernel-based systems. The granularity of processes should be curtailed when performance is critical. Security is a spectrum, and such a system can still be more secure than the status quo. Limited kernels should be colocated next to processes again, not always across address spaces (since Meltdown), deferring to a cross-address space kernel on the harder-to-secure paths. If a process has a timer capability, and likely will for its remaining lifespan, an optimization could have a stub kernel accepting timer syscalls and forwarding the rest. Lastly, and this is a broader problem in most software, both code and state must be located in their proper places[1]. Use Parnas' criteria [2] for modular programming. If you believe in the power of the concept of microkernels, I have this to sell you; I believe it's even more basic and necessary. It's probably one of the most fundamental concepts we have on how to write good code.

[0] https://www.usenix.org/system/files/osdi24-chen-haibo.pdf [1] https://dl.acm.org/doi/10.1145/3064176.3064205 [2] https://wstomv.win.tue.nl/edu/2ip30/references/criteria_for_...

[Rochus]

That's interesting, thanks for the explanation and the references. Of course I agree with Parna's modularization principles, and having spent a lot of time with different versions of the Oberon and Active Object system I think that a microkernel is a natural fit. You seem to be a scholar of microkernels; are you also developing microkernels?