|
By No author listed, Lxrun - Technical Overview, June 2002
|
|
|
Document contents:
Lxrun is an emulator for executing Intel Linux a.out and ELF binaries on other types of UNIX® running on Intel x86. It was developed originally on and for SCO OpenServer and SCO UnixWare.
Lxrun does system call remapping "on the fly." There isn't a significant
difference between the execution environment required by Linux and SCO binaries. The primary difference is the way in which system calls are handled.
In Linux, an int $0x80 instruction is used, which jumps to the system-call-handling portion of the Linux kernel. On SCO systems, int $0x80 causes a SIGSEGV signal. Lxrun intercepts these signals and calls the SCO equivalent of the system call that the Linux program attempted.
There is also some mapping of ioctls, various flags, return values, and error codes. The result is that the Linux binary runs--with the help of lxrun--on the host platform with a small (usually negligible) performance penalty.
Because lxrun is effectively a system call emulator, it requires copies of the
Linux dynamic loader (ld-linux.so.1) and whatever Linux shared libraries are required by the program being run.
Most programs that do not rely on Linux-specific idiosyncracies or deal directly with hardware should work under lxrun.
The official lxrun web page is http://www.ugcs.caltech.edu/~steven/lxrun/.
In addition to what is found on the Sun web site, most applications we
tested worked. Aside from the standard applications bundled with Red Hat 5.2
(rpm, shells, and non-/proc commands) here are the other primary applications:
- KDE
- Gnome
- WordPerfect 7
- WordPerfect 8
- Applix
- Quake2
- GIMP
- Netscape Navigator
- Netscape Communicator
These applications were shown at the LinuxWorld show in San Jose in March 1999. Because lxrun requires the supporting libraries from a Linux installation (in this case, Red Hat 5.2), the Linux ext2 filesystem was ported to the Solaris operating environment.
It is simplest if you dual boot Linux and Solaris on a machine: Mount the Linux ext2 filesystem on /linux, and then point lxrun at it.
The hardware used at the show consisted of the following: 400Mhz Pentium II (1 UP, one 2-way), 128Mb, on-board ATI Rage 3d Pro. Quake2 was run with no hardware acceleration and just the software X renderer with the shared memory extension.
Lxrun is available from:
As other means to obtain lxrun become available, we will update this document.
The Lxrun package includes:
- lxrun
lxrun.tar.gz is a gzip-compressed tar file on the machine lxrun workspace. Inside is a precompiled binary that was built on the Solaris 7 operating environment.
- ext2 filesystem support
ext2fs.tar.gz is a gzip-compressed tar file of ext2fs filesystem and source. Inside is precompiled ext2fs modules and mount commands for both SPARC and x86 (also for Solaris 7). It only supports read-only access now, but appears stable.
- Quake2 support files
quake2-3.20-6.i386.rpm,
quake2-3.20-glibc-6.i386.rpm,
quake2-3.20-i386-unknown-linux2.0.tar.gz, and
quake2-3.20-glibc-i386-unknown-linux2.0.tar.gz are the Linux Quake2 binaries for glibc and non-glibc based Linux, in both RPM and gzipped tar format.
These files are also available from ID software, but are included here in case they change incompatibly (these files were used for testing and demonstrated at LinuxWorld).
You'll also need the pak files from the Quake2 CD (which you must buy).
- Sound drivers
www.4front-tech.com makes Open Sound System drivers, which work on a variety of platforms, including the Solaris operating environment. They provide the API that Quake2 uses for sound.
Note: They don't work on a DEBUG kernel (DEBUG catches a bad bcopy() from the driver, apparently), and if you have a startup script to enable the sound, as they suggest, it has no effect because the modunload that runs at the end of /etc/rc3 will unload the driver. Thus, Quake2 wrapper was written that enabled the drivers instead.
- Set up a Linux distribution for the Solaris operating environment to access.
This can be done any number of ways, such as from another disk through the Solaris ext2fs filesystem (described below), from a copy, or directly via NFS from a Linux machine. By default, lxrun will look for this distribution in /usr/local/linux, but you can set the environment variable LINUX_ROOT to wherever you put it. This is a very important point.
- Untar the lxrun tar file, and either build it from source (preferred), or grab the prebuilt lxrun binary.
The Makefile is set up to build for Solaris; whereas the final source from the official web site will probably use configure (as it does today if you get lxrun from that site). Place the binary wherever you like.
- The PATHMAP file.
This file tells lxrun how to remap file accesses when the Linux binary tries to open files. For example, if the Linux binary tries to open /etc/passwd, it probably wants to see the Linux password instead of the Solaris /etc/passwd. Thus, lxrun translates a request to open /etc/passwd into a request to open $LINUX_ROOT/etc/passwd. The PATHMAP file controls what is remapped and how. We remap almost everything.
By default, it looks for /usr/local/lxrun/PATHMAP, but you can set the environment variable LINUX_PATHMAP to the actual lxrun location, such as /home/yourname/lxrun/PATHMAP.
Now you should be able to run lxrun, such as:
lxrun /usr/local/linux/usr/bin/netscape
or, if you want to be in a completely Linux world, start a shell:
lxrun /usr/local/linux/bin/csh
Your account probably needs to be visible to both Linux and the Solaris operating environment applications. If the Linux setup you're using can't look you up, applications run by lxrun will not be able to find you, either. This can mean that the application won't run (e.g., Applix), will core dump (e.g., Gnome), or just won't work properly. The simple thing to do is to make sure you're in the Linux /etc/passwd
file.
If you're using a name service, like NIS, you might have other problems: Applications might wedge when trying to look you up because they cannot contact
the name service. For example, if you're dual booting Linux and Solaris, and
mounting the Linux filesystem, Linux apps will try to look for the file
/var/yp/binding/.2 in the Linux area. If they don't find it, they hang. The problem is that when Linux is shut down properly, ypbind will delete that file, so it won't be there when running Solaris. A solution under Linux is to copy that file, kill ypbind, then restore the file before shutting down Linux.
- Untar the ext2fs tar file, and either rebuild from source (preferred) or use
the prebuilt binaries.
- From the right directory (SPARC or i386), copy the "ext2fs" module to
/usr/kernel/fs and the "mount" binary to /usr/lib/fs/ext2fs/mount. The getext2fs script was run to install it on the test machines. No 64-bit module is currently available.
- Find your Linux drive and add an entry to
/etc/vfstab for it. On SPARC, the entry might look like this:
/dev/dsk/c0t0d0s0 - /linux ext2fs - no ro
On x86, it might look like this:
/dev/dsk/c0t0d0p1 - /linux ext2fs - no ro
(Use "yes" instead of "no" if you want it mounted at boot). This is just for the root drive; add more if you need to mount other partitions.
- No write support.
- Rebooting may fail to sync the filesystem (only because ext2fs is not
releasing resource correctly; other filesystems should still be properly synched). This primarily seems to happen when you export ext2fs over NFS.
Useful Links
|
|
Print-friendly Version
