There may by cases where you want to generate a Linux binary on a FreeBSD machine. This is not a problem with the linuxulator, but not with the default linux_base port.
As you may know, the linux_base port is designed to deliver an integrated experience with FreeBSD native programs. As such some parts of the native FreeBSD infrastructure is used. If you would try to use a Linux–compiler to generate Linux–binaries, you would run into the problem that by default the FreeBSD includes are used.
To have a fully featured and non-integrated Linux environment on your FreeBSD system either mount an existing (and compatible) Linux installation somewhere into your FreeBSD system, or install a linux_dist port. This can be done additionally to an already installed linux_base port.
When you have a complete Linux environment available, you need to mount the FreeBSD devfs to /path/to/complete_linux/dev, linprocfs to /path/to/complete_linux/proc and linsysfs to /path/to/complete_linux/sys to have a complete setup.
Now you just need to chroot into this /path/to/complete_linux and you configure/make/install or whatever you need to do to generate your desired Linux binary.
A while ago I committed the linuxulator D-Trace probes I talked about earlier. I waited a little bit for this announcement to make sure I have not broken anything. Nobody complained so far, so I assume nothing obviously bad crept in.
The >500 probes I committed do not cover the entire linuxulator, but are a good start. Adding new ones is straight forward, if someone is interested in a junior–kernel–hacker task, this would be one. Just ask me (or ask on emulation@), and I can guide you through it.
, gt 500
, kernel hacker
, little bit
Seems I forgot to announce that the linux_base-c6 is in the Ports Collection now. Well, it is not a replacement for the current default linux base, the linuxulator infrastructure ports are missing and we need to check if the kernel supports enough of 2.6.18 that nothing breaks.
To my knowledge, nobody is working on anything of this. Anyone is welcome to have a look and provide patches.
This weekend I made some progress in the linuxulator:
- I MFCed the reporting of some linux-syscalls to 9-stable and 8-stable.
- I updated my linuxulator-dtrace patch to a recent –current. I already compiled it on i386 and arundel@ has it compiled on amd64. I counted more than 500 new DTrace probes. Now that DTrace rescans for SDT probes when a kernel module is loaded, there is no kernel panic anymore when the linux module is loaded after the DTrace modules and you want to use DTrace. I try to commit this at a morning of a day where I can fix things during the day in case some problems show up which I did not notice during my testing.
- I created a PR for portmgr@ to repocopy a new linux_base port.
- I set the expiration date of linux_base-fc4 (only used by 7.x and upstream way past its EoL) and all dependent ports. It is set to the EoL of the last 7.x release, which can not use a later linux_base port. I also added a comment which explains that the date is the EoL of the last 7.x release.
, expiration date
, kernel module
, kernel panic
, linux base
, linux module
Last weekend I committed some dummy-syscalls to the linuxulator in FreeBSD–current. I also added some comments to syscalls.master which should give a hint which linux kernel had them for the first time (if the linux man-page I looked this up in is correct). So if someone wants to experiment with a higher compat.linux.osrelease than 2.6.16 (as it is needed for a CentOS based linux_base), he should now get some kernel messages about unimplemented syscalls instead of a silent failure.
There may be some low-hanging fruits in there, but I did not really verify this by checking what the dummy syscalls are supposed to do in linux and if we can easily map this to existing FreeBSD features. In case someone has a look, please send an email to emulation@FreeBSD.org.
, kernel messages
, linux base
, linux man
, man page
, new opportunities