Moving code into applications (was Re: Information on implementing L4)
paul at boddie.org.uk
Mon Sep 17 15:54:55 CEST 2018
On Friday 14. September 2018 19.04.10 Andrew Warkentin wrote:
> On 9/14/18, Paul Boddie <paul at boddie.org.uk> 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.
More information about the l4-hackers