Lin­ux­u­la­tor ex­plained: How to cre­ate Linux bin­ar­ies on FreeBSD

There may by cases where you want to gen­er­ate a Linux bin­ary on a FreeBSD ma­chine. This is not a prob­lem with the linuxu­lator, but not with the de­fault linux_​base port.

As you may know, the linux_​base port is de­signed to de­liver an in­teg­rated ex­per­i­ence with FreeBSD nat­ive pro­grams. As such some parts of the nat­ive FreeBSD in­fra­struc­ture is used. If you would try to use a Linux–com­piler to gen­er­ate Linux–bin­ar­ies, you would run into the prob­lem that by de­fault the FreeBSD in­cludes are used.

Pre­requis­ites

To have a fully fea­tured and non-​integrated Linux en­vir­on­ment on your FreeBSD sys­tem either mount an ex­ist­ing (and com­pat­ible) Linux in­stall­a­tion some­where into your FreeBSD sys­tem, or in­stall a linux_​dist port. This can be done ad­di­tion­ally to an already in­stalled linux_​base port.

Pre­par­a­tion

When you have a com­plete Linux en­vir­on­ment avail­able, you need to mount the FreeBSD devfs to /​path/​to/​complete_​linux/​dev, lin­procfs to /​path/​to/​complete_​linux/​proc and lin­sysfs to /​path/​to/​complete_​linux/​sys to have a com­plete setup.

Use it

Now you just need to ch­root into this  /​path/​to/​complete_​linux and you configure/​make/​install or whatever you need to do to gen­er­ate your de­sired Linux bin­ary.

Linuxu­lator D-​Trace probes com­mit­ted to cur­rent

A while ago I com­mit­ted the linuxu­lator D-​Trace probes I talked about earlier. I waited a little bit for this an­nounce­ment to make sure I have not broken any­thing. Nobody com­plained so far, so I as­sume noth­ing ob­vi­ously bad crept in.

The >500 probes I com­mit­ted do not cover the en­tire linuxu­lator, but are a good start. Adding new ones is straight for­ward, if someone is in­ter­ested in a ju­nior–ker­nel–hacker task, this would be one. Just ask me (or ask on emu­la­tion@), and I can guide you through it.

linux_​base-​c6

Seems I for­got to an­nounce that the linux_​base-​c6 is in the Ports Col­lec­tion now. Well, it is not a re­place­ment for the cur­rent de­fault linux base, the linuxu­lator in­fra­struc­ture ports are miss­ing and we need to check if the ker­nel sup­ports enough of 2.6.18 that noth­ing breaks.

TODO:

  • check for up­dated RPMs for linux_​base-​c6
  • cre­ate linuxu­lator in­fra­struc­ture ports
  • im­prove the ker­nel to sup­port more of linux 2.6.18

To my know­ledge, nobody is work­ing on any­thing of this. Any­one is wel­come to have a look and provide patches.

Linuxu­lator pro­gress

This week­end I made some pro­gress in the linuxu­lator:

  • I MFCed the re­port­ing of some linux-​syscalls to 9-​stable and 8-​stable.
  • I up­dated my linuxu­lator-dtrace patch to a re­cent –cur­rent. I already com­piled it on i386 and arundel@ has it com­piled on amd64. I coun­ted more than 500 new DTrace probes. Now that DTrace res­cans for SDT probes when a ker­nel mod­ule is loaded, there is no ker­nel panic any­more when the linux mod­ule is loaded af­ter the DTrace mod­ules and you want to use DTrace. I try to com­mit this at a morn­ing of a day where I can fix things dur­ing the day in case some prob­lems show up which I did not no­tice dur­ing my test­ing.
  • I cre­ated a PR for portmgr@ to re­po­copy a new linux_​base port.
  • I set the ex­pir­a­tion date of linux_​base-​fc4 (only used by 7.x and up­stream way past its EoL) and all de­pend­ent ports. It is set to the EoL of the last 7.x re­lease, which can not use a later linux_​base port. I also ad­ded a com­ment which ex­plains that the date is the EoL of the last 7.x re­lease.

New op­por­tun­it­ies in the linuxu­lator

Last week­end I com­mit­ted some dummy-​syscalls to the linuxu­lator in FreeBSD–cur­rent. I also ad­ded some com­ments to syscalls.master which should give a hint which linux ker­nel had them for the first time (if the linux man-​page I looked this up in is cor­rect). So if someone wants to ex­per­i­ment with a higher com­pat.linux.osrelease than 2.6.16 (as it is needed for a CentOS based linux_​base), he should now get some ker­nel mes­sages about un­im­ple­men­ted sy­scalls in­stead of a si­lent fail­ure.

There may be some low-​hanging fruits in there, but I did not really verify this by check­ing what the dummy sy­scalls are sup­posed to do in linux and if we can eas­ily map this to ex­ist­ing FreeBSD fea­tures. In case someone has a look, please send an email to emulation@​FreeBSD.​org.