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],
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
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
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 :-)
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 | email@example.com
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.