Re: Design Decisions and Hurd/L4 work (was: Re: Improving Hurd)

[Jeroen Dekkers]

On Sun, Apr 21, 2002 at 07:31:22PM +0200, Farid Hajji wrote:
> [Cc: l4-hurd, since it covers Hurd/L4-relevant stuff. Please Un-CC
> when L4 is no longer concerned. Thanx]

Or Un-CC help-hurd when we are talking about L4 stuff only. :)
 
> > > > I think you may find that this will improve with the change from
> > > > Mach to L4.  But imagine if the first year had been used to analyze
> > > > and specify it.
> > > 
> > > Why? The Hurd is not Mach, or L4, it is just a bunch of translators and is
> > > quite independent of Mach. Yes, we do use drivers and such from it, but I
> > > don't see why it would change anything if we change to L4.  Sure, we might
> > > get some speed, but until I see some numbers that the Hurd runs faster
> > > on L4 I won't believe it. :)
> 
> The purpose of the Hurd/L4 port is not primarily speed, but to get
> a better design of the Hurd. If speed is your concern, there are lots
> of possible improvements in Hurd/Mach right now. Just think of
> unnecessary copying, the fork() issue, etc... All this _could_ be
> fixed by any knowlegeable Hurd hacker right now. But it is still
> too early to optimize for speed, since we have more pressing issues
> to solve.

I think there is another reason to port: L4 is maintained and under
development, Mach is quite death.

> The Hurd/L4 port forces us to rethink many design decisions that
> were valid at the time when Mach was the only available microkernel.
> This is not to be taken lightly; because we must first really understand
> what Roland, Thomas and others had in mind in misc. parts of the code.
> I'll be the last one to suggest throwing good code away!

I think the nice thing about the Hurd and glibc is the code reuse
which is possible. It has a good coding style, it's well commented and
it's highly portable.
 
>    Preconditions for uvmserver are:
>      * We need threads, because UVM (and therefore uvmserver)
>        is inherently threaded. Now, native L4 threads API (V4),
>        later Pthreads + a suitable C-Library with Pthreads
>        support. Considered OSKit's UVM, but depends on
>        OSKit's libc_r (FreeBSD). Hmmm...
<snip>
> 3. The Pthreads issue needs to be fixed.
> 
>    Jeroen is doing this right now for glibc/mach and IIRC all
>    it would take to port this to L4 (Version 4) would be a
>    set of additional sysdeps.
> 
>    As soon as Pthreads is stable enough, CThreads will need to
>    be phased out in favor of pthreads. Once this is done, a big
>    milestone would have been achieved towards porting the Hurd
>    to anything else than Mach.
> 
>    Of course, a glibc wizard will need to port glibc to L4
>    so that we can _use_ Jeroen's Pthreads for L4 threads :-))

I think it isn't difficult to make a kind of stand-alone
pthreads+glibc implementing the pthread_*() functions and the OS
independent functions like the string functions if that would be
needed.

Jeroen Dekkers
-- 
Jabber supporter - http://www.jabber.org Jabber ID: address@hidden
Debian GNU supporter - http://www.debian.org http://www.gnu.org
IRC: address@hidden

pgpunbnthN_xt.pgp
Description: PGP signature