3 ms·
FreeBSD emulating Linux has way less performance overhead than either emulating Windows. FreeBSD's Linux "emulator" consists in a substituted syscall table and
by ketralnis 10y ago
FreeBSD emulating Linux has way less performance overhead than either emulating Windows.
FreeBSD's Linux "emulator" consists in a substituted syscall table and a kernel module for implementing syscalls that aren't native to FreeBSD (like epoll).[0][1]
Here's an example of what that means. When a FreeBSD binary wants to delete a file it calls the syscall unlink(2). So it's executing as a regular old binary, does a regular syscall, specifies the unlink syscall number, the kernel looks up that syscall number in that binary's (FreeBSD's) syscall table, and jumps to that code.
When you execute a Linux binary on FreeBSD you also execute it as a regular old binary except that you specify to use the Linux syscall table instead of FreeBSD's (IIRC this is done by the elf loader, so you're not even saying "linuxrun ./mybinary"; you're just saying "./mybinary"). It's executing more or less identically to a FreeBSD binary except that when it's time to delete a file it looks up the unlink system call in the Linux syscall table and jumps to that instead. Some of the arguments or calling conventions are different so most of the calls have a shim to rearrange stuff for the FreeBSD equivalents before calling into the same code the FreeBSD binaries are using. This is the same thing that FreeBSD does to support ABI versions for old versions of itself, to support SysVR4 binaries[2], and it's the same trick that SmartOS's Linux zones use as well[3]
What this means is that if your binary isn't using a lot of linuxisms, they execute at nearly identical performance.
Wine is using a pretty similar trick--trying to directly execute the binary while intercepting win32 API calls--but the impedance mismatch between posix and win32 is much higher so the cost of those shims is going to be much higher. The DeleteFile win32 API function takes a LPCTSTR that needs to be decoded, its return values have different meanings, and its semantics around files opened by other processes is different. And obviously for more complex calls the difference widens: the difference between simply speaking x11 over a socket vs calling MessageBox is much larger.
[0]: https://www.freebsd.org/doc/handbook/linuxemu.html https://www.freebsd.org/doc/handbook/linuxemu.html
[1]: https://www.freebsd.org/doc/en/articles/linux-emulation/inside.html https://www.freebsd.org/doc/en/articles/linux-emulation/insi...
[2]: https://people.freebsd.org/~newton/freebsd-svr4/ https://people.freebsd.org/~newton/freebsd-svr4/
[3]: https://www.youtube.com/watch?v=TrfD3pC0VSs https://www.youtube.com/watch?v=TrfD3pC0VSs
- Longhanks 10y agoAlso, Linux emulation is probably a lot easier to implement, since there is complete source code access available. Emulating the Win32/NT kernel syscalls is basically reverse engineering, which makes the progress much harder.
- SolarNet 10y agoHence why WINE is better for emulating older programs. Whereas the linux subsystem is usually up to date.
- ketralnis 10y agoThe linuxulator tries to be compatible with Linux 2.6.16 (released March 2006). I'm not sure about Wine but at a glance they mention 64-bit support so I'd guess at least Vista (also 2006)
- asveikau 10y agoThat's kernel abi though. My guess is a lot of code in glibc in particular handles ENOSYS with some reasonable fallback and so you can have a newer userland.