A while ago I com­mit­ted the lin­ux­u­la­tor D-Trace probes I talked about ear­lier. I waited a lit­tle bit for this announce­ment to make sure I have not bro­ken any­thing. Nobody com­plained so far, so I assume noth­ing obvi­ously bad crept in.

The >500 probes I com­mit­ted do not cover the entire lin­ux­u­la­tor, but are a good start. Adding new ones is straight for­ward, if some­one is inter­ested in a junior–ker­nel–hacker task, this would be one. Just ask me (or ask on emu­la­tion@), and I can guide you through it.

Seems I for­got to announce that the linux_base-c6 is in the Ports Col­lec­tion now. Well, it is not a replace­ment for the cur­rent default linux base, the lin­ux­u­la­tor infra­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 updated RPMs for linux_base-c6
• cre­ate lin­ux­u­la­tor infra­struc­ture ports
• improve the ker­nel to sup­port more of linux 2.6.18

To my knowl­edge, nobody is work­ing on any­thing of this. Any­one is wel­come to have a look and pro­vide patches.

This week­end I made some progress in the lin­ux­u­la­tor:

• I MFCed the report­ing of some linux-syscalls to 9-stable and 8-stable.
• I updated my lin­ux­u­la­tor-dtrace patch to a recent -cur­rent. I already com­piled it on i386 and arundel@ has it com­piled on amd64. I counted 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 after 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 notice dur­ing my testing.
• I cre­ated a PR for portmgr@ to repocopy a new linux_base port.
• I set the expi­ra­tion date of linux_base-fc4 (only used by 7.x and upstream way past its EoL) and all depen­dent 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 com­ment which explains that the date is the EoL of the last 7.x release.

Last week­end I com­mit­ted some dummy-syscalls to the lin­ux­u­la­tor in FreeBSD-cur­rent. I also added 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 some­one wants to exper­i­ment with a higher compat.linux.osrelease than 2.6.16 (as it is needed for a Cen­tOS based linux_base), he should now get some ker­nel mes­sages about unim­ple­mented syscalls instead of a silent failure.

There may be some low-hanging fruits in there, but I did not really ver­ify this by check­ing what the dummy syscalls are sup­posed to do in linux and if we can eas­ily map this to exist­ing FreeBSD fea­tures. In case some­one has a look, please send an email to emu­la­tion@FreeBSD.org.

It seems my HOWTO cre­ate a new linux_base port was not too bad. There is now a PR for a Cen­tOS 6 based linux_base port. I had a quick look at it and it seems that it is nearly usable to include into the Ports Col­lec­tion (the SRPMs need to be added, but that can be done within some minutes).

When FreeBSD 8.3 is released and the Ports Col­lec­tion open for sweep­ing com­mits again, I will ask port­mgr to do a repo-copy for the new port and com­mit it. This is just the linux_base port, not the com­plete infra­struc­ture which is needed to com­pletely replace the cur­rent default lin­ux­u­la­tor user­land. This is just a start. The process of switch­ing to a more recent linux_base port is a long process, and in this case depends upon enough sup­port in the sup­ported FreeBSD releases.

Atten­tion: Any­one installing the port from the PR should be aware that using it is a highly exper­i­men­tal task. You need to change the lin­ux­u­la­tor to imper­son­ate him­self as a linux 2.6.18 ker­nel (described in the pkg-message of the port), and the code in FreeBSD is far from sup­port­ing this. Any­one who wants to try it is wel­come, but you have to run FreeBSD-current as of at least the last week­end, and watch out for ker­nel mes­sages about unsup­ported syscalls. Reports to emulation@FreeBSD.org please, not here on the webpage.