On 4/6/21, Royce Mitchell III <[email protected]> wrote:
>
> 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.
_______________________________________________
Devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to