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

Porting the Hurd to L4 (glibc dependencies, dropping glibc?)

Is it _absolutely_ necessary to use glibc with the Hurd?

It seems that many hurd servers and libs are using glibc like
any other C library except for:


and of course MiG-generated stubs in <hurd>/*/.deps plus a few places
that use mach_*() syscalls directly. There are some few more dependencies
which would have to be taken care of.

To help porting the Hurd to other systems (not only to L4), it would be
a good idea to:

1. retrofit all hurd specific glibc functions into a separate library
   (let's boldly call it libhurd). The reason for this is to reduce
   the dependency of the Hurd from glibc, which is not available on all

2. clean up the Hurd libs and servers, so that they use (the rest of) glibc
   rather conventionally. The goal is to be able to link the Hurd against
   libc's of other OS (plus a ported [part of] libhurd), thus "borrowing"
   features of existing host OS kernels like threads, tasks, etc... or
   using ukernels like gnumach and L4 directly.


1. The Hurd could be built on non-glibc based systems and run on top
   of these (as sub-hurd). I can imagine running the Hurd on a FreeBSD
   box, where the Hurd uses dedicated partitions (or vn(4) files) and
   where it is linked against FreeBSD's libc (and an adapted libhurd[-bsd],
   see below).

2. Misc. abstractions that the Hurd needs (threads, tasks, etc...) could
   be either implemented by a dedicated microkernel (gnumach, L4, ...)
   or could be "borrowed" from an existing libc of the hosting OS.
   In the above example, threads and processes etc. would be provided by
   FreeBSD kernel+libc.

3. The Hurd could be run in "demo-mode" inside existing OS, just by
   borrowing most of the local libc/kernel services. This way, more
   users would be able to run the Hurd and get first experiences with it.

4. Porting the Hurd to non-x86 architectures could be a two step process:
   First run the Hurd as sub-hurd on an existing host OS of that architecure,
   then port L4 (or some other small ukernel) to that platform and relink

To achieve this goal, a lot of work is needed (or course!). If we decide
to give it a try, I'd suggest the following path:

1. First of all, move all hurd glibc functions into a separate library
   (libhurd). Later, this library will have to be split into two
   parts: A hurd generic part that is independent of Mach or any other
   ukernel, and dependent parts (one for gnumach, one for L4, one for
   each supported host OS which calls that OS's libc directly to "borrow"
   abstractions like threads etc...).

2. Examine the Hurd sources carefully, looking for glibc idiosyncracies,
   that are not available on other libc's. Revert to the least possible
   interface common to most/all libc's of the host OSes (at least Unix-
   like OSses for now).

3. Remove the Mach dependencies in the Hurd sources themselves, by replacing
   them with calls to libhurd[-mach]. As was already suggested by others,
   mig could be modified to produce more generic stubs to libhurd rather
   than libmach.

If I could only find a way to cross-compile the Hurd, glibc, mig and
gnumach on FreeBSD, I'll try to get the Hurd run on FreeBSD as sub-hurd
first and will start working on an L4 part next. The more help I'll get,
the better :-)

Any suggestions?



P.S.: I don't have anything against glibc. Dropping glibc dependency from
      the Hurd is purely an architectural issue that would help support
      the notion of "host OS running sub-hurd" as well as to help isolate
      the current Mach dependencies of the Hurd.

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

Reply to: