> The Hurd GLibC has a special property: It has almost the same interface
> as the Linux GLibC,
> because it comes from the same source tree.
This is an interesting approach! We should really investigate this issue
further. As long as the Linux sysdeps have Mach/Hurd equivalents, it
has a real chance to succeed and would BTW eliminate the syscall redirect
overhead.
As you pointed out, the following drawbacks should not prevent us from
trying to achieve ABI compatibility to Linux' glibc:
* Statically linked binaries (even to the recent/current glibc) will
not work because they still contain the syscall traps.
* Binaries linked against older libc's (libc5) won't work either.
* Non glibc based binaries (like *BSD and others) won't be supported.
As a FreeBSD user, I'm not very well versed in current Linux distributions.
But it is probably a good guess to assume, that some important binaries
there are statically linked and that others are only being ported slowly
towards libc6/glibc2, right? Considering this, a simple binary ABI compat
between the Hurd's and Linux' glibc(s) won't be enough to be able to drop
the Hurd and Mach into an existing Linux distribution and be able to
boot that alternative Kernel (or should I say microkernel + set of servers?).
Contrast this to the RT-Mach/Lites/FreeBSD approach which supports syscall
redirection and which uses an unmodified FreeBSD distribution as a host
environment of the Mach/Lites kernel replacement. In this environment,
one can use the same system either by booting the regular FreeBSD kernel
or by booting rtmach/lites at the boot prompt. Everything else (well,
_nearly_ everything else ;-)) remains the same, except that we can also
compile and run Mach-based programs directly and that some FreeBSD kernel
drivers or pseudo-drivers are missing in the Lites server... From the point
of view of a distributor, the Lites approach seems superiour at first glance,
if you disregard the syscall redirect and other overheads.
Now imagine that we've got the syscall emulation in the Hurd. If you
dropped that enhanced Hurd as a simple package in FreeBSD and boot
it, you may be even able to do a 'make world' and recompile the complete
FreeBSD distribution (minus the FreeBSD-Kernel and -glibc themselves)
directly against the Hurd's glibc, effectively eliminating every syscall
redirect overhead and turning the FreeBSD distribution into a native Hurd
distribution with a *BSD flavor. Still adding precompiled FreeBSD packages
would be possible, if you keep the old FreeBSD libc' around and still
redirect to it.
Sure, some incompatibilities are bound to remain, considering that
many sources depend on interfaces (and header files) that are kernel
dependent (think of networking and other stuff). At least, autoconf'd
programs will easily recompile. The remaining stuff is probably the
same that the debian people are now currently struggling to port.
The same holds true for Linux distributions that are selfhosting, i.e. that
can recompile themselves with a simple command. As long as the binaries
and libraries are not dependent on some esoteric kernel [pseudo-]drivers
that are missing in Hurd/Mach, nothing objects against working on the Hurd
and try to turn in into a kernel substitute that can be dropped into
existing distributions.
> 1. The Hurd uses stdio, while Linux uses libio.
What's the problem here? Is it not possible to isolate libio into a
separate library and have the loader link linux binaries against it?
I don't know libio. If it completely relies upon open(2), read(2), write(2)
and other regular unix system calls, it can be compiled separatly from
stdio and Linux idiosyncracies?
> 2. The Hurd does not have pthreads.
Thats true... Was not someone already working on this? I'm not sure wether
newer Machs added p-threads to their c-threads libraries. It may be a
good idea to ask CMU, Utah, OSF and Keio/NTT, wether there are plans to
implement p-threads in the near future or wether they are already present
in some new experimental Mach release. At least, we could avoid having to
adapt e.g. LinuxThreads or other threads package to Mach threads.
> Only for direct use of syscalls we would need the syscall trap and
> emulation you explain
> in your proposal.
Well, if someone is willing to devote time and efforts into the syscall
trap redirection stuff, I'm willing to help too. But I don't have the
time right now to concentrate on this issue exclusively ;-)
-Farid.
--
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.
