BSDI beta testing Linux Application Platform

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.

Comments

Linux /Emulation/?

[questionlp]

It's kind of nice to see another BSD distribution (albeit it's a commercial version of BSD) pick up on the Linux /emulation/ feature.

Sure the /emulation/ may not be perfect under FreeBSD, but it allows me to run Linux versions of Pine 4.20, Netscape 4.7, and WordPerfect (although the FreeBSD port is a bit faster and more stable, but the Linux version uses a bit less RAM).

Something I would really like to see more of would be more companies port [free or non-free] software over to xBSD. The market share for xBSD isn't as huge as the Linux share, but many people still choose BSD over Linux for one reason or another. Just like the previous Sun JDK port for FreeBSD article, many companies are pushing for Linux a bit too much... remember, the Open Source movement's goal is to provide the ability to share software and source freely to anyone... and to help provide alternatives to the current software out there.

Re:Linux /Emulation/?

[kkenn]

Actually, it's not emulation in the sense of a virtual machine, but an alternative syscall interface to the kernel. See this for an excellent explanation of the process.

As for WP using more memory, are you sure you're not confusing it with this?

Re:Linux /Emulation/?

[questionlp]

I know it isn't really emulation... that's why I surrounded the word emulation without slashes. It's my way to say that it's not really what it means, but it's the only word I can think of at that moment.

I was running `top' to see how much space in memory was used for WordPerfect... and the Linux version used about 1MB more than the ported version. But 1MB really doesn't kill me since I have 256MB installed on that machine.

But so far... `top' states that neither of my machines (one with 256MB of RAM and one with 64MB of RAM) hasn't used swap space yet. I guess that's a good thing ;)

Re:Linux /Emulation/?

[Anonymous Coward]

Unpredictable dependencies between everything and everything -- you don't upgrade applications and libraries, you upgrade the system.

This is real bitch with using FreeBSD. There is such an ugly spider web of dependencies, everything is cross-coupled in mysterious ways. It violates one of basic axioms of engineering complex systems: loose coupling, decoupling.

Even though I use FreeBSD, I think one of Linux's strengths is its modular nature. It is much easier to drop a software package into Linux and make it work. Under FreeBSD, software tends to break when moved between release versions. The only way to guarantee a consistent FreeBSD system is to rebuild everything (make world).

Re:Linux /Emulation/?

[stripes]

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.