> 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 | [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
