[Top][All Lists]

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

Re: HURD - About compatibility with another S.O.

From: Marcus Brinkmann
Subject: Re: HURD - About compatibility with another S.O.
Date: Wed, 4 Apr 2001 19:16:29 +0200
User-agent: Mutt/1.3.15i

On Wed, Apr 04, 2001 at 09:15:53AM -0700, Jeff Bailey wrote:
> As far as I can tell, binary compatability will be an accidental side
> effect of bringing our libc in sync with the one that Linux uses.

> I think it's an awful idea.  If we start to claim that we can run
> Linux binaries, people will wonder why *some* don't work.

And, *shock*, they might learn something about the compatibility issues you
mentioned in consequence :)

> Anything
> that uses a Linux specific syscall, ioctl, device, 'proc filesystem'
> will fail to run under The Hurd.

We can emulate linux syscalls in a library. ioctl numbers and provided
functionality will differ (I think you can have a replacement library to
override glibcs idea of a ioctl, and map linux ioctls to hurd features
though -- which requires a special invocation of the binary, defeating the
idea of transparent emulation a bit). We can probably have a procfs
emulation for linux, although this is stretching it, IMO.

The point is that only system specific programs will/should use these system
specific programs. We don't have much need for linux system programs. But it
is a benefit to have a compatibility at the glibc ABI level for user
applications. (Some people would mention binary only software here, but I
mention convenience (why recompile?) which can be exploited by a clever
packaging and ftp archive system, and broader testing of the ABI).

> It also means that we tie ourselves
> to matching whatever they choose, whether it's the Right Thing or not.

I don't know if I understand what you mean, but no, we are not limiting
ourselve to what linux does. The ABI exposed by glibc is not determined by
the linux kernel. And the emulation of syscall will be in a distinct


`Rhubarb is no Egyptian god.' Debian
Marcus Brinkmann              GNU

reply via email to

[Prev in Thread] Current Thread [Next in Thread]