Re: L4Mach or Refactor Hurd Servers?

[Farid Hajji]

> libports is a pretty good approximation of what we (the Hurd developers)
> think an IPC system ought to provide for server writers.  It is certainly
> an open question as to how much is done in the microkernel's IPC system and
> how much is done in a user-level library.  We do have strong opinions about
> the guarantees that should be provided, and have designed the Hurd around
Yes, that is exactly what libports is about. I must admit that I often tend
to mix libports mach-specific implementation with its external interface.
You will probably admit, that using buckets of port rights etc... leads
one strongly to the assumption, that the uKernel has to provide the same
services. Its sometimes difficult to separate Mach implementation from
the generic support that the underlying kernel (or VK/L4, if we were to
add L4 support to libports) should provide.

> these assumptions (such as that no-senders notifications are guaranteed to
> be delivered soon when a task and all its send rights get destroyed, and
> this cannot be broken by any user-level action).  (When I was working on
Absolutely. No-senders/dead port notification is one of the hardest parts
to port to a non-mach kernel, like L4.

> the now-dead Fluke microkernel at the University of Utah, which had an IPC
> system somewhere in between Mach and L4 but much closer to L4 in its
> simplicity, we implemented a libports-like abstraction layer with the same
> essential properties as Hurd's libports on top of the much simpler
> microkernel abstractions.  Of course that work was never really finished
> and research on that microkernel was abandoned before it was entirely
> usable.)  
Interesting insight. I often wondered what happened to the Fluke project.
They didn't resume work nor published anything new in the last couple of
years. That's sad.

> People keep saying they think the Hurd is "deeply wedded" to Mach IPC.  I
> think all those people are just not really looking at the fundamentals of
> the Hurd code.  Yes, we use MiG RPC presentations and Mach port operations.
> But aside from syntax that is trivial to change, we have a fairly small
> number of dependencies on Mach's idiosyncratic IPC features (like send-once
> rights and disconnected RPC).
Agreed. Most of it _is_ either syntax or can be replaced in a 1:1 manner
(like vm_*()). As you've put it, the problem is with the disconnected
RPC, send-once and, most importantly, dead-port notifications.

> We have always been opening to redesigning
> parts of Hurd implementation to fit better with different IPC systems.
> Noone has ever gotten specific about what they want to do.  I'm not sure
Well, if you ask for a wish-list, here is one: ;-)

  * IPC should be only used in stubs during an RPC.

    This is very important. Most IPC in the Hurd occurs during
    an RPC call. Most RPC calls _can_ be done in a completely
    synchroneous manner. By sticking to this requirement, it
    would be pretty easy to extend whatever stub generator's
    backend to support L4-based IPC.

    BTW, it would be very helpful to move away from MIG towards
    something more portable. One possible candidate would be
    flick, because it has backends for Mach3 but also for L4.
    As an L4-related example, the educational demo multiserver
    SC/OS uses exactly flick 1.x's L4 backend.

    There has been dissent about flicks' generated stubs and
    skeletons' performance, both under Mach3 and L4. I'm not
    fixed towards flick: we could roll our own portable stub
    generator if we can get volunteers. Right now, flick is
    there and can be used immediately. As long as we use IDL,
    that would be fine.

  * VM should be accessed through vm_allocate(), vm_deallocate(),
    vm_map(), vm_unmap() _only_. Maybe vm_remap(), later.

    Please don't meddle with the default-pager directly, unless
    this is done through a well-defined interface that we could
    emulate/reimplement in an L4-based [UVM-?]pager.

    Is there anything that really _requires_ pager-magic that
    is not covered by the vm_*() calls above? Please let us
    know, so we can try to take this into account in the L4
    pager. L4 itself is pretty strong w.r.t. memory management,
    providing things like page grants, mapping into other tasks,
    using recursive pagers etc... I'd prefer not having to use
    all of this though ;-)

  * Redesign libports by providing a clear separation between
    Mach-specific things and the interface that is needed by
    Hurd servers.

    This is the hardest part of the port. Sincerely, is libports
    really necessary to the Hurd, when run on top of non-Mach?
    I'm not really sure if I understand the purpose of libports
    correctly, so please feel free to comment here.

    Isn't it the domain of the stub generator to provide for
    the code that manages low-level [kernel-] IPC handles like
    port rights and the like? Instead of putting this into
    buckets, wrapping classes around them etc.., this looks
    like it really belongs in the stubs. We may need a powerful
    stub generator [backend] for Mach, that could integrate
    some of libports? Then again, the stub generator for the
    L4 port would so something else. I've not made up my mind yet.

    Anyway, a good and clear separation of Mach-things and the
    Hurd interface in libports would be very useful.

  * <More to come ;-)>

> that I'm on the l4-hurd list, so perhaps there has been some discussion
> there that I haven't seen.  But every time someone posts to bug-hurd with
> their opinion about the Hurd's relationship to Mach, they speak in
> completely vague general terms and never present anything concrete about
> the details of the IPC system they'd like to work with, how they would
> adapt the Hurd to use it, and what the problems might be.
The discussions on l4-hurd currently boils down to this:

  * the VM semantics of Mach will be met by implementing an
    l4-based pager task. This pager would probably not use
    Mach-VM directly, but the improved NetBSD UVM variant.

    The L4-based pager will have an IPC interface of some
    kind (as specified in an IDL spec) and can thus be
    RPCed directly. The preferred way to IPC the pager would
    be provided by a helper library that will implement
    the vm_*() calls mentioned above.

  * the drivers will be implemented in user-level tasks.

    One possibility that was discussed is to use OSKit drivers
    directly. This may not be so good, because OSKit links in
    a lot of other stuff and thus unnecessarily bloats binaries.
    
    Another possibility is being investigated by the L4Env
    group at University of Dresden. They plan to provide a
    L4 framework, where the sourcecode of current (I think
    it was 2.2.x, not 2.4.x) Linux drivers could be simply
    dropped in and where they would build user-level driver
    tasks. I've not yet looked at this though.

    As far as the Hurd is concerned, I can imagine that a
    Mach-like API glue could be written, so that those new
    drivers can be accessed like Mach devices.

  * It seems like there is agreement, that L4 IPC will not
    be used directly but only through an IPC stub generator
    that could adapt to new revisions of the L4 API. There
    are two reasons for this:

    The L4 API is currently being revised and is expected to change in
    the near future.  We have to use existing L4 kernels now, so we
    can't use a not-yet stabilized new API with the current kernels.
    Using a stub generator will isolate VK/L4 or the Hurd from such
    fluctuations.

    The other obvious reason is that code written in IDL is much
    more portable. All that is needed is a pair of different stubs,
    one for Mach, and one for L4. This can be achieved in the
    stub generator alone, e.g. using two different IDL-generators
    or an IDL-generator with two different backends (like flick).

If you want to have a glimpse on a simplest multi-server OS running
on top of L4 and using flick, please look at SC/OS:

  http://www.l4ka.org/projects/SCOS/
  http://i30pc11.ira.uka.de/~kevinelp/sysimpweb/example/dev.html

I suppose that the Hurd port will use similar techniques.

> As to your specific question, I can't imagine that anything you might call
> "L4Mach" would be a worthwhile thing to do from a Hurd perspective.  But I
> am only guessing what you really have in mind, since you have not been at
> all specific.
Yes, I agree here. L4Mach will not be something like, say, Lites.
We will have to implement some Mach functionality like VM and the
drivers, and the Hurd people will have to help us with the wish list
above. For the drivers, we'll probably follow the L4Env group's work.

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.