help-hurd
[Top][All Lists]
Advanced

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

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


From: Farid Hajji
Subject: Design Decisions and Hurd/L4 work (was: Re: Improving Hurd)
Date: Sun, 21 Apr 2002 19:31:22 +0200 (CEST)

Hi Atle,

it may be futile, but let's try to put this thread back on
track by talking about what can be done _now_ and postpone
the philosophical issues for later. Sorry for interfering
in that very amusing discussion and for forking off another
thread. ;-)

[Cc: l4-hurd, since it covers Hurd/L4-relevant stuff. Please Un-CC
when L4 is no longer concerned. Thanx]

> > > 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.

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!

> Well, now you are at center of the what I think is the problem.
> Who says either of Mach or L4 is even suitable for this purpose?
> There was a possibility of a total 'Faridization' of the whole thing 
> (sorry, Farid, 
>       (you can imagine how many dinner parties I get invited to) 
>   I don't even know if you remember it, 
>  but we did talk about implementing a kernel with a minimal API)
> and it was concluded that nobody would agree to it.

Hmmm..., I'm not sure I understand what you're meaning here.
I suggested for purely technical reasons to take the misc.
Hurd components apart and port them separately to L4 (or
VK, whatever you prefer), then to integrate everything back
to a cohesive whole. There are probably other engineering
methods to port the Hurd, but I'm not aware of them. Please
enlighten us all if you have a more sensible method in mind.
We're all pretty lazy, so we're always happy to hear about
ways to save us unnecessary work :-)

I case you missed the last postings in l4-hurd, this is what
the current roadmap for the Hurd informally looks like. If you
want to contribute, please do so.

1. Port a few key drivers from OSKit to userspace.
   We need keyboard, vga, serial(!) and, for the ambitious,
   support for ATAPI disks (swap files etc...!).

   The port can be done from within Hurd/Mach by sticking to
   Mach's way of delivering interrupts as messages and by
   mapping I/O space into the address space of the userspace
   drivers that need it.

   Try to do this in a portable manner, keeping at least in
   mind how L4 delivers (and clears) INTs and how L4 maps
   I/O (and memory-mapped) address spaces to userland spaces.

   Anybody with driver experience can start immediatly here.
   There are no preconditions for this work.

   [Thanks Marcus for suggesting to start with the drivers!]

2. We need a VM server for L4 that will provide Mach's vm_*()
   semantics (or the big subset thereof that is used by the Hurd
   right now).

   I'll refer to my postings on l4-hurd regarding 'uvmserver'.
   Anybody willing to help is strongly encouraged to drop me
   (or l4-hurd) a note so we can do this together.

   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...
     * We need at least a disk device driver for swap files;
       though at the moment, we can use some spare physical memory
       as pageout area ;)
     * Pretty good understanding of UVM internals.

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 :-))

4. Espen is right now coding the Pistachio L4 kernel that will
   implement X.2 (and later Version 4) API.

   Did you really read the X.2 specs? ;-)

   In the meantime, we're using Hazelnut for simple tests and
   hacking to get acquainted to L4. The old X.0 (and X.1) APIs
   are not as clear as X.2 (V4), but it's better than nothing.

5. IDL4 has just been released and some of us are already
   investigating it or planning to do so in the next couple
   of weeks.

   So, not only theoretically, you can right now code a few
   L4 tasks and have them RPC each other via IDL4-generated
   stubs rather than using raw L4 IPC syscall. This is a big
   improvement to what we had before (if you didn't use DICE).

   If you are really ambitious about writing an OS from scratch
   using ADTs and coding them in C++, L4 + IDL4 is probably the
   way to go. If you prefer to reuse code, try to build an
   infrastructure similar to the Hurd's (a.k.a. write libraries)
   and port the translators directly. Hmmm..., quite demanding,
   isn't it?

6. Concerning port rights, we'll use a pragmatic approach by
   simply coding a port-rights server as L4 task and providing
   a library that will IPC that server upon requests by Hurd
   processes.

   This is far from optimal (I'm still hoping that some kind
   of distributed credentials system can be designed or implemented;
   or that we could even rely on L4's security features like
   sending address etc...), but it would at least work.

   The biggest problem was no-senders notifications. I said "was",
   because it can be solved by having the task-server (which in
   L4 will always be notified of the "death" of a task [so to say])
   notifying himself all interested parties (a.k.a. translators).

   As far as coding is concerned; just use IDL4 for the RPCs.
   It's pretty easy for anybody with enough spare time. Just
   give it a try.

   Preconditions for the port-rights server:
     * We need threads for a multi-threaded server.
       A single threaded server could be enough as a first shot,
       as long as the whole mappings are memory resident and accessed
       quickly enough. But we'll need the multithreaded version
       very soon, because this will be a major bottleneck of
       the Hurd/L4 system (just a wild guess for now).

7. Real hard stuff.

   As soon as the basic work has been done (uvmserver, portserver,
   userspace drivers, pthreads in glibc and the Hurd, glibc port
   to L4), we'll have enough ground work to start porting the Hurd
   for real.

   This is the part that will get quite hairy and where we can
   (and most likely will) err most.

   Basically, we have two possible ways:
     * Port almost everything by adding support from below (say,
       add more infrastructure until we can compile the Pthreaded
       and Un-Mach-ed Hurd sources on top of L4+MachEmulation).
     * Restarting from scratch by porting single components,
       have them synchroneously IPC via IDL4 (or whatever)
       and then link everything back into the big root-tree.

   I have no preferences whatsoever here; simply because I have
   no clue at all what would be feasible or easier to do. Both
   approaches have pros and cons and we'll have to strongly
   discuss them when that issue becomes real. But until then,
   I'd suggest to concentrate on laying down the foundations
   by doing some homework ;)

   BTW, it would be a _very_ good idea to get in touch with SawMill
   and other distributed OS teams to learn from them too, once we
   have reached stage 7.

Regards,

-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.




reply via email to

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