On Mon, May 27, 2024 at 9:13 PM David Holland <dholland-t...@netbsd.org> 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".
