Preliminary support for running 32-bit Linux binaries

[Tim Robbins]

On Fri, Jun 18, 2004 at 09:34:59AM -0700, David O'Brien wrote:
> On Fri, Jun 18, 2004 at 01:43:53AM +1000, Tim Robbins wrote:
> > I'm pleased to announce that my work on running 32-bit Linux binaries
> > on FreeBSD/amd64 has come to the point where it runs almost everything I
> > throw at it, including the Sun JDK, OpenOffice.org and Acrobat Reader.
> > 
> > The patch and some brief notes on installing the Linux base system and
> > a few popular applications are available at:
> > http://people.freebsd.org/~tjr/linux32.html
> 
> You've been using Slackware bits, but the project has settled on Red Hat
> bits for 32-bit x86 Linux support.  Can you retest with the same 32-bit
> bits as in ports/emulators/linux_base/?

I'll try that, but I would eventually like to see linux_base updated to
a non-obsolete version of Red Hat / Fedora Core so that recent applications
are more likely to work. We would need to be careful to avoid bringing in
an NPTL libpthread library though.

(I initially chose Slackware because it's clean, simple, obvious, and easy to
install without a fully-functioning emulation environment. It's also a lot
smaller to download over my poor modem.)

> I feel we should install your bits into sys/amd64/linux32/ and leave
> sys/amd64/linux/ for the 64-bit Linux compat bits.  This module's
> Makefile should live in sys/modules/linux32/ also.

Agreed. I had planned to do this before committing it to CVS, as well as
renaming the files in amd64/linux to linux32_foo.c. We still need a way
to avoid clashes on global symbol names (e.g. we can't call both the 32-bit
and 64-bit versions of the "stat" syscall linux_stat()), and I haven't come
up with an elegant way of solving this. This is only an issue if we want to
have both 32-bit and 64-bit Linux emulation compiled into the kernel at the
same time; everything should work fine if either or both are loaded from
modules. I'm leaning towards doing something like what we do in imgact_elf.c.


Tim