On 4/6/21, Royce Mitchell III
I'm guessing that maybe this is purely an OS design decision and not the purvue of the kernel itself. Perhaps init could launch a "service manager" process that would be responsible for starting up services and drivers for example and this "service manager" could provide an IPC endpoint back to init (or whomever) to use for IPC discovery. Then, whenever a new process is started, it is provided with the IPC discovery endpoint information that it is to inherit.
UX/RT, the OS that I'm writing, will implement service discovery similarly to QNX Neutrino or Plan 9. All services will be discovered exclusively through the filesystem. Each process will be provided with a permanently-open file descriptor allowing it to communicate with the VFS and open more files. File descriptors will be implemented as a thin wrapper over seL4 IPC, and read/write/seek-family APIs will communicate directly with other processes rather than being forced to go through a specific intermediary server (this will eliminate the chicken-and-egg problem that would otherwise occur when trying to communicate with the VFS itself over a file-based transport).
If a central service manager is needed to glue the core OS together, does it represent a single point of failure and how would the OS recover if it crashes and loses it's database of available services without having to rebuild and restart all drivers and services? (I'm not saying that's a bad thing, just trying to wrap my head around how this particular part of seL4 works)
UX/RT will have the VFS and process/memory management built into the root server and all other services implemented as regular processes with no special semantics, much as under QNX (although of course the process/root server won't be built into the kernel as in QNX). The VFS will be way too intertwined with memory management to separate it out (UX/RT will be the only OS I'm aware of in which literally everything is a file; even anonymous memory will be replaced with mapped files in a tmpfs), so I'm not going to bother with trying to allow recovery from VFS crashes, at least not at first. The root server will be written in Rust so it will have a lower risk of memory bugs than if it were written in C.