Re: L4 instead of gnumach?
On Mon, Oct 30, 2000 at 06:28:41PM +0100, Niels Möller wrote:
> Erik Verbruggen <firstname.lastname@example.org> writes:
> > Ok, I think the L4 stuff needs a bit of background. Special for Niels: I
> > started doing a Sparc port, but there were some problems which are
> > similair to those that the Alpha port has, so that's why I react.
> Thanks for the info. I've tried browsing
> http://os.inf.tu-dresden.de/L4/, but I haven't yet found the
> definition of the "L4 µ-kernel API". Do I have to get some source
> archive for that (and if so, which source; there seems to be several
Well, there is a "user manual" for the MIPS port which is very good.
> My concerns last time I looked at L4 was
> (i) It was written in C++, which I dislike (that's a religious
> question, and this is not the right place to argue the details).
Erm, ok, you took that implementation ("problem" with L4 on Intel is
that there are actually 3 implementations). This is the better one in my
The sole reason for them to use C++ is that it saves typing work (that's
their statement). I've had this discussion before with someone, and
his/her problem was the overhead C++ code has. Well, C++ only generates
overhead with dynamic typing and templates, none of which they use as
far as I can see. But this can be modified. Note: I'm no C++ freak, nor
C freak, so I don't mind etc.
> (ii) The "clans and chiefs" model seemed odd. As I said, I think
> ports and send rights are quite sane and easy to understand.
> (see "An Ode to the Granovetter Diagram,
Well, as the user manual states, this is used to see if thread can send
messages to another thread in another clan. *If* L4 is used to run HURD
on top, this can be used to check the port rights.
> When I look now, it seems there are several implementations, not all
> C++, which is good. So (i) seems solved. As for (ii), I would be happy
Well, the one in C++ is the cleaner one, as far as I can see. I can be
wrong (really, I'm open to this, but mail me personally :), and the C++
stuff can be removed quite trivially.
> if you who are looking into L4 could tell me that you know how to do
> HURD security or capability-style security on top of "clans and
> chiefs", and that it won't kill performance. If you also have the time
> to explain how to do it, that would of course be even better.
As L4 does not provide all stuff needed for GNUMach interfacing, the
additions will decrease performance for sure. No doubt about that. As I
stated above, the chief thread can do the port-rights I think.
> A short list of features one gains or loses when moving from Mach to
> L4 would also be nice (efficient asyncronous "messages", network
> transparent ipc, transfer of send rights, friendliness to higher level
> ipc-services (say GNOME's corba stuff), etc).
I thought about CORBA too as replacement for MIG. With respect to L4 it
has the advantage that it "flattens" the IPC message, if I understand it
correctly. I think something with the messages is needed, as L4 wants a
message to be in a page so it can do message passing by MMU page
remapping (which gains speed). But I'm not 100% sure about all IPC
details in GNUMach, CORBA, MIG and L4. Note: It's not that I *want*
CORBA, but I've taken a serious look at it.
> Ok, that's a fair amount of questions. I would appreciate answers, but
> I also understand if you want to spend your time hacking rather than
Heh, yes, you have a point there. I'm a bit biassed to do a fair bit of
thinking before, because my current job involves (among things) removing
stufid decisions of others. I quite dislike to work on something and
throw it away later on. Sorry for that. That's also why I want to work
on the drivers first, as this will be a benefit for all ports (I hope).
And yes, I did some work on this with GNUMach, but that's not for public
consumption yet :)
One more final note: it's not that I want to do away with GNUMach, more
that GNUMach has its "problems", and for porting L4 is a good starting
point candidate, for reasons mentioned before.
Well, that's all, Erik.
Erik J. Verbruggen, email@example.com, Daneel on IRC,
room A5005 science faculty KUN, phone: +31-24-3652229