Re: /proc and other Linuxisms

[Farid Hajji]

> believe that using /proc things in a program leads to non-portable
> programs, so it should just aim at giving useful pieces of information to the
> user (not the programs) I think.

How right you are! As a FreeBSD user, I'm often really upset about
the extensive use of Linux' /proc FS by some apps. Fortunately,
this bad habit is not very common yet, so that we can bear with it
(for the moment).

The problem is not with the small GPLed apps which could be modified,
but with the biggies like, say, StarOffice and so on. FreeBSD circumvented
this portability problem by providing a linux emulation ABI of its own,
together with a Linux' style /proc FS, which is just a subset of the
true Linux /proc, but which is sufficient to support most Linux binaries
right out of the box.

Okay, enough grumbling about non-portable Linux apps ;-)

People interested in implementing a Linux compatibility ABI for the
Hurd should consider a few facts which make this a relatively easy task:

  * Linux apps are mostly dynamically linked against glibc. The Hurd's
    version of glibc presents the same ABI interface to apps. Through
    some linker magic, it _may_ be possible to run native Linux apps
    directly under the Hurd [1]. Thanks Marcus for pointing this
    out many months ago! ;-) BTW, has anybody tried this out?
    I suppose that crt0.o should be replaced, but the rest could
    be quite easy. Some ld expert out there?

[1] The apps must not call the kernel directly through syscall traps
    since this would result in a Mach exception being raised. Statically
    linked apps consist of such syscall traps, but dynamically linked
    apps would typically do syscalls indirectly through glibc, so no
    problem there. Of course, calls to linux-specific drivers (like
    say, sg etc...) are tabu!

  * It is possible to implement more than just one binary ABI at the
    kernel syscall layer. Look at the way how the FreeBSD Linuxulator
    works: Under FreeBSD syscalls (traps) are intercepted and routed
    through an ABI switch which redirects the call to the misc.
    binary compatibility modules that are provided. Actually, FreeBSD's
    Linux compatibility mode is not an _emulation_, but a second ABI.
    Which one is faster/better/native? All of them are!

  * Mach provides a mechanism for syscall redirection (emulation vectors)
    which works roughly like the FreeBSD ABI: If you install the proper
    emulation vector in Mach, you can have Mach intercept the Linux
    syscall trap and redirect it (as a message) to an emulation library
    preloaded in the address space of the calling task. Now, you "just"
    need to write such an emulation library and have it preloaded before
    the task is started.

> The list archive also shows post regarding a Linux binary emulation layer? Has
> there been any work on it? Any pointers?

AFAIK, no work has been done there yet. If you want to help, please
do read Helander's master thesis on Lites to understand what is needed.
Then please read the OSF mach docs, especially the section on
emulation vectors and look at the Lites source code.

If you need more infos, don't hesitate to ask!

> Cheers,
> Ludovic.

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.