On Sat, Aug 26, 2000 at 04:26:29AM +0200, Farid Hajji wrote:
> > 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.
I think that some of the Linux syscalls can be redirected to glibc calls,
others to hurd library functions, and some probably not so easy. However, as
many, many programs don't use linux syscalls directly, following this
approach would be a high benefit for little work.
And of course, the syscall emulation/redirection, as you explained it, can
and should follow afterwards (I say afterwards because I imagine it takes
more time to implement, there is no real requirement that it comes later
than glibc ABI compatibility).
> 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.
That's a good one, I was not aware of this drawback. Luckily, notm any
programs are statically linked. Maybe some non-free binary only apps.
> * Binaries linked against older libc's (libc5) won't work either.
Again, for some old binary-only, non-free apps this will be a problem, but
something that will be fixed by other people, as libc5 is phasing out in the
linux world rapidly.
> * Non glibc based binaries (like *BSD and others) won't be supported.
Yes, this is a real limitation, of course. Your broader approach would
tackle all of these.
> 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?
No, not really. There are a few people who were dependant on libc5 for their
work, but this is a rare exceptioon rather than the rule. Even commercial
non-free apps are in almost all cases available for glibc by now.
> 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?).
Let's say that you replace the Linux kernel + init and some other small
programs. Let's also exclude network utilities, were Linux has a more
complete support for. Then what you say would work to a certain amount.
I wish I had some figures about how many linux binaries use syscalls
directly, but I don't. Some netutils, sysvinit (unnecessarily, btw).
Probably some more.
> 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.
Yes, I think that's about how the situation is.
> > 1. The Hurd uses stdio, while Linux uses libio.
> What's the problem here?
Roland fixed the existing problem in the exec server, so the road should be
free to switch over. However, it is an interface change (all binaries will
break), so we hold it off until a flag day, where we make all interface
changes at once. Less work for everyone.
> Is it not possible to isolate libio into a
> separate library and have the loader link linux binaries against it?
I don't know. Considering that we really want to use libio on the Hurd as
well, it makes change to play with a libio glibc for the Hurd now.
> > 2. The Hurd does not have pthreads.
> Thats true... Was not someone already working on this?
Mark Kettenis worked on it, and neal Walfield (hi Neal!) gave it some
consideration. I don't know the curretn state but I think Mark stalled
development on it (correct me if I am wrong). Any person around who has a
copy of the pthreads standard on the shelf?
> At least, we could avoid having to
> adapt e.g. LinuxThreads or other threads package to Mach threads.
Right, although merging both efforts in a single threads package might be
useful.
> > 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 ;-)
Anyway, it's a thrilling idea, and our ressources should allow us to have
glibc ABI compatibility at least (and leave syscall redirection for later).
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
[EMAIL PROTECTED], [EMAIL PROTECTED] PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
