Re: Pthread assumption + starting real port

[Farid Hajji]

>   For me, that seems like you want to do a catastrophic revolution. If
> you rewrite only auth, how will the whole system run? That makes
> sense, only if you can continue your work with a non-working system
> for the long. As a long-time contributor to free software, I know
> that's _rarely_ feasible. Therefore, I suggested making Mach emulation
> first. Mach emulation itself is surely bad, but we would make it
> possible to allow both Mach-dependent code and libmom'ish code to
> co-exist at the same time with it. For example, rewriting auth for L4
> wouldn't affect the other parts, even if you don't rewrite other
> servers or libraries. This way, it would be possible to throw away all
> of the Mach-things, while the transition is gradual.
Nothing prevents us from doing both things. Actually, the approaches
are not _that_ far away, as it seems. I've looked at auth in more detail
and I'm currently writing up a (semi-formal) specification for a new
auth, that should additionally support something like stored capabilities
(one thing that l4-mach is certainly supposed to do).

auth may be small and uninteresting at first sight, but the more one
thinks about it, the more potential one can see. Give me a few days
do sort things out and come with a concept that we could work on. I'm
just now trying to figure out what kind of authentication protocol between
the Hurd components and regular clients poses less strain on auth/l4-mach,
especially with respect to scaling and (later) distributing over a set
of nodes.

The biggest difference between l4-mach and auth/proc rewrite is that
the second approach requires a formal specification of what the Hurd
components should do and how they are supposed to interact. This is
a bottom-up approach that can be gradually implemented (component-wise)
so we get more and more parts of the system working. I agree with you
about the difficulties in the free software world concerning such hard
projects and I do share some of you concerns. I hope however, that once
a formal specification of everything is complete, we can find people
willing to implement and test the single modules.

>   Another thing: why do you want to discard glibc so much? Is there a
> better alternative?
I don't want to _discard_ glibc right away. I just want to relax the
dependency of the Hurd from glibc. There are numerous reasons to do so:

1. glibc is much harder to port to another platform than most of other
   GNU software. How would you port glibc to L4? Without Unix semantics
   on the target platform, you'll need to redo the hurd sysdeps completely
   from scratch and that's always a _lot_ of work. Then again, why not?
   I'm not that fiercly opposed to glibc than it sounds.

2. Besides glibc, other C libraries are conceivable, some of which also
   freely available. Just think of *BSD libc's, which also happen to
   be integrated in OSKit. Ever benchmarked FreeBSD's libc and glibc?

3. Retargeting the Hurd to libmom, relaxing the glibc dependancy would
   permit to use Hurd/L4 as a drop-in replacement "kernel" for existing
   non-glibc based systems. Just consider Lites/rtmach, which can execute
   the same FreeBSD binaries transparently without recompiling. If the
   Hurd were independant of glibc, it could well run binaries of systems
   that are not linked against glibc by trapping the native syscalls and
   redirecting them into libunix (just like Lites work).

   This doesn't mean that we shouldn't use glibc at all; we're just
   having more free choice of options.

4. Separating the hurd from glibc means:
     * getting a leaner glibc,
     * isolating unix personality syscalls in a separate library,
     * having to think more about the separate components,
     * implementing a distributed hurd cluster more easily (more on
       this later).

5. Developing and then running Hurd components on top of a libmom-{guestos}
   is only possible, as long as nothing in the Hurd relies on features
   that are available in glibc _only_.

6. <other reasons go here...>

I acknowledge that the C library plays an important role in the design
of every OS and that calls to C library functions mostly end up in syscalls.
It seems just a good idea to consider the Hurd system as a whole like a
big program with defined interfaces (the Unix emulation syscalls, a.k.a.
libunix) which could be called by the stubs of existing C libraries like
glibc, *BSD libc or (through dynamic relinking) other exotic/non-free libc's.
[Of course, some of the actual implementation practices that result from
the intimatly knit Hurd and glibc would have to be better designed. More
on this later]

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.