Re: Re: Mach independence

[Roland McGrath]

> One good example is how to implement vm_*() functions in VK/L4: [...]

As you are already aware, this is exactly what I'd like to see.  If you
plan to base anything on NetBSD UVM, you should look at what was done with
uvm in the oskit; a summer student at Utah did an oskit encapsulation of
uvm.  I don't know if that was in a released snapshot yet, but you can get
it; ask the oskit folks for details.  I'm sure it's quite rough, but it
might be a cleaner place to start (if you buy into the oskit plan for
modularizing the stolen code and plopping in newer versions from the origin
system later on).

It's also worth talking to the Utah folks (Mike Hibler in particular) about
the whole VM server design question.  We started on this path in the
never-finished Fluke system, which has a microkernel VM interface more
similar to L4's than any other system I'm aware of.  (I don't quite
remember L4's details well enough to compare them, except to recall that
it's about the same except for being inside-out wrt control flow.  There
was a time 3 or 4 years ago when there was comprehensive knowledge of the
L4 design that informed the Fluke design, and someone from there other than
me might remember the details or even have written them up.)  I believe
Mike had implemented anonymous paging but not the external pager RPC
interface, which is of course the really hairy part.

I am also interested in the possibility of piecemeal replacement of
Mach functionality in oskit-mach or variants thereof (or sideways
addition of new subsystems for a compatibile path to replacement if
it's not too hairy).  I could see a) replacing Mach VM with a oskit
uvm component or b) replacing Mach VM with an L4/Fluke-level AS
remapping interface requiring a user-level memory manager.  I prefer
the latter, since I really find the L4/Fluke style the proper
abstraction level for a microkernel (i.e., the microkernel just
presents a safe and portable interface to the hardware AS switching,
MMU cache, and page fault handling).

> Another example are device drivers. We (l4-hurd) are investigating
> two alternatives: OSKit maintained drivers and the L4Env environment
> that must still be released by Dresden University. In any case, it
> will be probably easy to provide glue code that will mimick Mach's
> device framework dev_*() functions. Here again, I expect no necessary
> changes to the Hurd's codebase.

Speaking for the Hurd developers, we don't like the Mach device RPC
interfaces *at all*.  In fact, they suck rancid goat farts.
We would be completely happy with any one or more of the following:

* New device RPC interfaces that you can use for L4 and we can use for Mach.  
  That is, write some IDL and semantics that make sense,
  implement the server-side functions using oskit drivers
  with whatever semantic glue that requires (the RPC->oskit semantics
  part of the glue should be common to whichever kernel).
  We can write whatever little new Mach-specific glue is required. 
  Change Hurd callers of device_* to use new RPC signatures and semantics.

* Wholly new implementation of "device" store type for a different
  kernel.  Aside from libstore, the only other users of the device_*
  interfaces are pfinet, term, and streamio.  These could be
  conditionalized as well; we can live with that little ugliness.  We
  hope eventually to have an abstraction layer library for
  stream/packet devices analogous to libstore for addressable devices,
  at which point it would be only the device module in libstore and
  the device module in that new library that needed to be changed.
  This is exactly the kind of per-kernel porting work that it's
  reasonable to have in the Hurd code.

* Wholly new implementation of "device" store type doing user-level drivers.
  If you want to put drivers directly into the libstore framework,
  that would be cool with us.  We're not going to try it on Mach.
  IIRC the L4Linux implementation just runs at IPL0 to be able to
  efficiently handle interrupts by disabling them at the PIC from user-level.
  That is not a really safe and secure solution we would be happy with
  long term, but whatever you want to do to make l4-hurd work is fine by us.

> Once we've sorted out those things, changes to the Hurd codebase will
> be needed (but only then). Those changes would be mostly cosmetic in
> nature, (calling vk_*() functions instead of mach_*()), as well as
> using a hopefully portable IDL compilers for normal IPC.

We really want to have an RPC/ports interface that doesn't require the
Mach implementation to lose the efficiency we now get from the
Mach-specific features like MACH_MSG_TYPE_MAKE_SEND.  When I was at
Utah working on specifying the "VK" RPC interface for Fluke (we were
calling it "MOM") I came up with an opaque interface I could optimize
that way.  It should be possible to do that if the VK interface and
implementations are designed with careful thought.

> The issue of Pthreads vs. Cthreads will then also have to be dealt with.

I hope that it will not be another n years before we have a good libc
pthreads implementation and ditch cthreads.  If it happens the way it
should, it will be a portable implementation designed to share as much
code as possible between implementations for different underlying
kernels and already work on Linux and Mach; so adding L4 support
should not be hard.

When it comes time to worry about signals and so forth, I am
interested in having a better microkernel support interface that we
can also put into oskit-mach so that the libc code can be structured
the same way for both microkernels.  (I don't remember what L4 has,
but the thread-interrupt interface specified in Fluke is pretty close
to right for convenient implementation of Hurd signals/cancellation.)