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

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

On Mon, May 27, 2024 at 9:13 PM David Holland <dholland-tech%netbsd.org@localhost> wrote:
>
> Barrelfish? Also, compared to the cost of the rest of the system,
> dusting off a microkernel that's been on the shelf a bit is cheap.
> But IDK, I don't follow these in any detail.
>

Even the inactive L4-like kernels I'm aware of aren't any closer to
QNX Neutrino than seL4 is. Most of them lack capabilities entirely and
use threads as IPC destinations rather than having thread-independent
endpoints/channels (even the IPC gates in Fiasco.OC and NOVA are bound
to threads, whereas the only connection in MCS seL4 is that its
endpoints maintain queues of waiting threads). I guess VSTa's kernel
would be closer to QNX, but its IPC model isn't fully
capability-oriented (QNX's isn't either, which makes security more
complex than necessary; this is one of the issues with QNX I want to
fix in my own OS) and it only supports x86-32.

> I don't see the difference between what you're describing and the
> rfork/clone model. But in any event, the problems with pthreads
> remain; it's difficult to implement the pthreads behavior of
> fork/exec/wait in a model where threads aren't tied to processes.
>
In the traditional variant of the rfork()/clone() model, there is
nothing to visibly group related threads together, and the state
containers are anonymous and can't be manipulated directly, only
cloned. With the model I'm going to use, a process will be a group of
threads (rather than threads being a type of process), but will have
basically no state other than a list of threads and a command
line/environment, and state containers will be directly visible in
procfs. Every thread will belong to one and only one process. fork()
(which will be a library function that uses various state manipulation
APIs) will only fork a single thread. exec*() will replace an entire
process and all threads in it regardless of what state containers are
bound to them. wait() will specifically wait for an an entire process,
although it will be built on top of a more general API that can wait
for individual threads, entire processes, or entire cgroups.
>
> It only looks like Unix from the outside, and not all that much even
> then...
>
I guess it depends on which definition of "Unix" you consider the most
important. Usually I tend to consider "functional Unix" (which is a
matter of APIs and commands) more important than "conventional
functional Unix" (which is a matter of kernel internals). QNX 4 and
Neutrino certainly qualify as "functional Unix" the way I define it,
but definitely do not qualify as "conventional functional Unix".