Forgot your password?
typodupeerror
BSD Operating Systems

BSDI beta testing Linux Application Platform 5

brianm9 wrote in with this tidbit from BSDI's home page. "LAP enables a BSD/OS system to execute many dynamically linked Linux ELF binaries (both libc5 and glibc) with no significant loss of performance. This release has been tested with the following Linux applications: Adobe Acrobat, ApplixWare, Informix and Word Perfect." The beta is only available to BSDI customers with current support contracts; more information can be had from BSDI's Linux Application Platform page.
This discussion has been archived. No new comments can be posted.

BSDI beta testing Linux Application Platform

Comments Filter:
  • Comment removed based on user account deletion
  • Actually, it's not emulation in the sense of a virtual machine, but an alternative syscall interface to the kernel. See this [freebsd.org] for an excellent explanation of the process.

    As for WP using more memory, are you sure you're not confusing it with this [freebsd.org]?
  • Comment removed based on user account deletion
  • Actually while that is a good explanation of how the FreeBSD linux emulator works, it is not a good description of how the BSD/OS one works.

    The FreeBSD one has a lot of in-kernel goo to translate syscall numbers (and sometimes arguments) from Linux numbers/arguments to FreeBSD ones. It also does a useful bit of jiggering to make overlay the contents of /usr/compat/linux/ onto /.

    The BSD/OS one is 100% outside the kernel. It interposes a new libc shim between anything that looks for a linux libc and the real linux libc. the shim only contains syscalls (the stuff from section two of the manual), and makes BSD syscalls instead, sometimes re-jiggering the arguments. It does a similar overlay trick.

    The BSD/OS one has some minor advantages. Since it doesn't add anything at all to the kernel it doesn't increses non-swapable memory, bugs that could lead to panics, or kernel complexity. These are minor advantages becuase Linux emulation is a small kernel module, and barely does any of those things.

    It also has some disadvantages. It won't work for anything that makes syscalls without using the shared lib functions to do it. So no staticaly linked code will work. Nor will porgrams that do an inline expansion of the select syscall to make it work slightly diffently (that would be the Linux Netscape, and I assume other versions of Netscape as well).

    I'm going to have to say the disadvatanges are bigger then the advantages.

    In both cases the "emulation" is very fast. It is one basically a table lookup (or three) per syscall, and as syscalls are allready quite expensave, the extra work won't be noticed. Actually you might be able to notice a diffrence if all you do is call getpid(2), or getuid(2) a lot, but if you call write(2), read(2), or socket(2) then you won't be able to notice a diffrence.

    In both cases the "emulation" only maps Linux features onto existing BSDish features. The read and write calls will be handled, but syscalls that exist only (very few, I think clone is one, FreeBSD could handle it by doing an rfork(2), but BSD/OS can't currently) on Linux will not work.

    If the systems were farther apart then the emulation would be both harder to code, and possably introduce a real slowdown.

Why be a man when you can be a success? -- Bertolt Brecht

Working...