In case you have not noticed yet, KDTRACE_HOOKS is now in the GENERIC ker­nel in FreeBSD-cur­rent. This means you just need to load the DTrace mod­ules and can use DTrace with the GENERIC ker­nel.

In case you do not know what you can do with DTrace, take the time to have a look at the DTrace blog. It is worth any minute you invest read­ing it.

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.

I just updated to a recent -cur­rent and tried the new nullfs. Sock­ets (e.g. the MySQL one) work now with nullfs. No need to have e.g. jails on the same FS and hardlink the socket to not need to use TCP in MySQL (or an IP at all for the jail).

Great work!

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 fail­ure.

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.