Re: Possibility of basing a QNX-like OS on NetBSD?

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, May 25, 2024 at 05:48:56AM -0600, Andrew Warkentin wrote:
 > I'm currently working on a QNX-like microkernel OS based on a fork of
 > seL4 and an original root server. Recently I had someone suggest that
 > I should look at trying to turn NetBSD into a QNX-like microkernel
 > because seL4's focus is more on static non-Unix-like systems.

That's a curious proposition, kind of like suggesting you should
harness a dump truck to your horses because chariots are for racing.

I think the question you should be asking is what your goal is -- are
you using seL4 because you specifically want to leverage seL4's
properties? If so, launching off in another direction seems like the
wrong move. If not, there are other L4-style microkernels you can use
that don't have as many restrictions as seL4, and there's a largish
community of advocates that will each be eager to help you decide to
use theirs.

If on the other hand you're specifically interested in making
something QNX-like, you'll probably need to write most of it from
scratch, since the only way to get that level of small and fast is
careful integration and careful design balancing goals and costs.

In any event, NetBSD isn't a microkernel and turning it into one would
pretty much be a 100% rewrite, the existence of rump notwithstanding.
It would be expensive and probably not come out all that well.

If you want a single-server Unix on top of a microkernel, rump is
maybe not a bad place to start... but this has been done many times
before and you're probably better off using one of the existing
examples.

 > I also wish to disaggregate the usual Unix process model into a far
 > more thread-centric one where a process is nothing more than a
 > collection of threads that share a command line and get replaced on
 > exec, with all of the usual process state like virtual address space,
 > open file descriptors, and filesystem namespace being separate context
 > objects that have to be explicitly shared between threads, and the
 > basic process creating primitive just creating a completely blank
 > process that the parent explicitly initializes with all the necessary
 > state using various APIs (of course, there will be a library that
 > implements fork(), spawn(), and pthreads on top of this).

The primary reason the world's gradually moved from that model of
threads to a model where threads are second-class within processes
is... design stupidity in pthreads. If you want to support pthreads,
especially if you have any concerns about it being fast, don't go in
this direction.

 > Another thing that I'm not sure about is the real-time performance. In
 > addition to desktop and server use, embedded systems with hard
 > real-time constraints are also an important use case for this system.

In that case you want to stay a long way away from anything that looks
like Unix.

-- 
David A. Holland
dholland%netbsd.org@localhost