Moving code into applications (was Re: Information on implementing L4)

On Friday 14. September 2018 19.04.10 Andrew Warkentin wrote:
> On 9/14/18, Paul Boddie <[email protected]> wrote:
> >
> > It is interesting to consider Nemesis, which evolved into Xen, in this
> > regard:
> > 
> > https://en.wikipedia.org/wiki/Nemesis_(operating_system)
> > 
> > One of the goals was to support POSIX applications, and it was apparently
> > a usable system in its day, maybe still is.
> 
> I knew Nemesis and Xen were from the same group at Cambridge but I
> didn't know that there was much of a connection other than both being
> somewhat exokernel-ish.

Digging slightly deeper, my recollections may have been wrong: there may not 
be a strong technological connection between the two. But reading a little 
about Nemesis reminds me of certain things about L4Re:

"The guiding principle in the design of Nemesis was to structure the operating 
system in such a way that the majority of code could execute in the 
application process itself."

From what I've seen in L4Re in various places, there is a certain amount of 
device driver code registering itself for incorporation by application 
programs. I feel that this is a bit awkward - code getting run at program 
start-up to register itself in fixed-length arrays enumerating the available 
drivers (many of which may be irrelevant to a given platform) - and it surely 
blends different responsibilities into the same process, potentially leaving 
applications with access to I/O memory regions.

What my own rather elementary work does is to separate drivers out into 
separate servers. Since many of them do not need to actively communicate with 
other components - they either initialise peripherals and do practically 
nothing or they share designated memory with other tasks - the only cost of 
employing multiple servers is the accumulation of duplicate or superfluous 
code contributed by each one of them in their standalone form, which is why I 
have been trying to use shared libraries as much as possible.

The virtual filesystem libraries also seem to promote a "client-side" approach 
to providing such functionality. Looking at different filesystem architectures 
is another of my current activities.

Paul