Re: Linux/Hurd compatibility
On Sun, May 09, 1999 at 02:07:32PM +0100, edmundo@rano.demon.co.uk wrote:
> There are three main levels of compatibility:
>
> (1) Source-compatibility, meaning you can use the same source code.
>
> Source-compatibility depends on the source being written carefully.
> (People might just stick bits of assembly language in the source.)
Assembler would not be such a big problem on the same processor, because
assembler is even lower than the operating system interfaces.
> The Hurd is supposed to be source-compatibible with Linux. If a source
> package can not be built on the Hurd it's because of a bug in the Hurd
> or a bug in the source (if we call non-portability a bug).
Not exactly. The Hurd does not define arbitrary limits like PATH_MAX, which
are use in many Linux programs (about half a dozen or so I know of). The
Hurd is supposed to provide a POSIX compatible interface through glibc.
Linux is aiming at POSIX compatibility, too, which makes for the source
compatibility.
Because both use the same GNU libraries, source compatibilty is very high.
BUt not for system level programs like netkit and such.
> (2) Binary-compatibility, meaning you can use the same binaries,
> provided the binaries don't use system calls directly.
>
> Since Debian GNU/Linux and Debian GNU/Hurd use the same libraries,
> glibc2, etc, this should in principle be not too hard to achieve. The
> main problems are ... well, what are they?
We don't have a compatible ABI right now. For example, we are missing POSIX
threads. As soon as we have exactly the same interface, we can try.
> The first release of Debian GNU/Hurd won't be binary-compatibile, but
> later releases probably will be.
Maybe even the first.
> You might be able to have most binary packages shared between Linux
> and the Hurd (exceptions being, for example, sash and libc6 itself).
> In that case you could release a single CD image for both, perhaps
> with the installation tool asking whether you want Linux or the Hurd
> as your kernel.
This is true, better examples are netkit, and other low level stuff. Look
at the admin section, many things are not usable on Hurd. We can try to
emulate the Linux syscalls, which gives even more compatibility. We can also
try to fake a /proc hierarchy. Yet another stage. Lot of work, too.
> (3) System-call-compatibility, meaning you can always use the same
> binaries, even libraries and statically linked ones.
>
> To achieve this you would have to intercept system calls and emulate
> the foreign ones, which is quite a lot of extra work.
>
> There's no immediate demand for this, but it could be done if someone
> really wanted it.
The result will be something inbetween 2 and 3, I think.
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@
Marcus Brinkmann GNU http://www.gnu.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: