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

[Andrew Warkentin <andreww591%gmail.com@localhost>]

On Sat, May 25, 2024 at 3:04 PM David Holland <dholland-tech%netbsd.org@localhost> wrote:
>
>
> 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.
>

AFAIK the only other active L4-like kernels are NOVA and Fiasco.OC,
and neither of them have QNX-style long message support. seL4's memory
model is probably better for the system I'm working on; NOVA and
Fiasco.OC are more designed with strongly hierarchical systems in mind
where there are a few subsystem servers that each get their own memory
quota and hand out parts of that to child processes, rather than a
more traditional Unix-like model (I do plan to support memory quotas
and resource trading, although they won't follow a strict hierarchy).
There are several things I'd like to add to my fork of seL4, but most
of them should be simpler to add than long message support. The only
changes I could see myself making on a similar scale to long IPC would
be if there are issues with SMP scalability.

>
> 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.
>

That was pretty much my conclusion as 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.
>

My OS is going to be multi-server, although it will mostly have a
process-per-subsystem architecture like QNX does, and not a
process-per-component architecture like Genode or L4Re. Protection
domains correspond to subsystems more often than they do to
components, so there's not much point in splitting up components in a
lot of cases.

>
>  > 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.
>

I don't think I've seen any Unix-like OS that uses the thread model
I'm planning to use. They pretty much all either use a Plan
9/Linux-like rfork()/clone() "threads are processes sharing state"
model, or a Mach-like "processes consist of state and threads" model,
rather than a "state is independent of processes and explicitly bound
to specific threads" model. The model I'm planning to use is a close
match to that of seL4, where capability spaces and virtual address
spaces exist independently of each other and threads.

>
>  > 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.
>
QNX is Unix-like and has reasonable performance for real-time systems,
although of course it is quite different from conventional Unix in its
architecture.