[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Hurd-alpha-devel] Re: L4 instead of gnumach?

From: Erik Verbruggen
Subject: Re: [Hurd-alpha-devel] Re: L4 instead of gnumach?
Date: Mon, 30 Oct 2000 10:09:58 +0100

On Sat, Oct 28, 2000 at 09:14:18AM +0900, OKUJI Yoshinori wrote:
> From: Ron Farrer <>
> Subject: Re: [Hurd-alpha-devel] Re: L4 instead of gnumach?
> Date: Fri, 27 Oct 2000 16:19:30 -0700
> > This is not completely decided. A MACH emulation layer for L4 was the
> > original idea, but I'm completely open to other suggestions. 
>   To understand why Mach emulation is bad, you need to know how L4
> improved IPC performance. They have improved the performance in
> various aspects, but in simple words, they made IPC semantics more
> lean.

Sure: IPC mesages need to be aligned on page boundaries (as the message
passing actually is page passing inside the MMU), there is a limit of
128 threads in a task and so on.

> If you add the extra flesh again, the performance would be the
> same as Mach. In fact, they demonstrated this in the paper on
> Unix/L3. Anyway, read articles/papers on L3/L4 as many as
> possible. You should be able to realize how difficult getting good
> perfomance is. Very careful optimizations are necessary (e.g. see the
> paper on L4-Linux).
>   However, I think Mach emulation would be a good thing as the first
> step, because you will be able to investigate how different L4 is from
> Mach and what would be necessary to be done in details. But I'd like
> to point out that Mach emulation should be temporary but not a
> permanent solution.

Indeed. The nice thing about L4 is that it's simple and lean, and
therefore fast. The emulation layer will definitely reduce speed. For
example with IPC: I think the way to emulate the Mach behaviour (and to
circumvent the page alignment) is to copy contents into page aligned
memory blocks. But I think speed improvements can be done later on,
especially because it will need *careful* optimizations.

> > MACH uses cthreads, we figured it would keep things easier by going that
> > route. If you think otherwise I'd like to know why? 
>   Isn't your (ultimate) goal to remove Mach-things from Hurd? cthreads
> is a Mach-only multithreading method, while pthreads is designed for a
> platform-independent manner. In addition, obviously, much more
> programmers know pthreads than cthreads.

Um, how quickly will HURD/the HURD people switch to pthreads? I mean,
we want to run HURD on top of it, and HURD uses cthreads at the moment.

> > Overall we want to give HURD some type of direction to go and some type
> > of common goal for development. 
>   That's a very, very good thing. It is certain that big projects such
> as Hurd cannot be cooperatively developed without clear goals. I'm
> quite glad to hear that you make an effort. Please call me out when
> you begin the work. I'd like to participate. :)

We will have questions about drivers, and you did add Linux drivers to
GNUMach, no?

> (Of course, I won't devote myself to L4 until I finish the remaining
> tasks for GRUB 1.0, though...)

Now you talk about Grub.... :-)

Alpha still needs a multiboot loader (well, I can't find one). L4 is
loaded as raw image on Alpha at the moment. I don't know if you have
access to an Alpha, but it would be very nice to have a bootloader (for
example aboot) modified so it can load multiboot stuff.

Erik Verbruggen.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]