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.
Linux /Emulation/? (Score:1)
Sure the
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/? (Score:1)
As for WP using more memory, are you sure you're not confusing it with this [freebsd.org]?
Re:Linux /Emulation/? (Score:1)
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/? (Score:1)
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.