Category: Kernel

New oppor­tu­ni­ties in the linuxulator

Last week­end I com­mit­ted some dummy-syscalls to the lin­ux­u­la­tor in FreeBSD-current. I also added some com­ments to syscalls.master which should give a hint which lin­ux ker­nel had them for the first time (if the lin­ux man-page I looked this up in is cor­rect). So if some­one wants to exper­i­ment with a high­er compat.linux.osrelease than 2.6.16 (as it is need­ed for a Cen­tOS based linux_base), he should now get some ker­nel mes­sages about unim­ple­ment­ed syscalls instead of a silent failure.

There may be some low-hanging fruits in there, but I did not real­ly ver­i­fy this by check­ing what the dum­my syscalls are sup­posed to do in lin­ux and if we can eas­i­ly map this to exist­ing FreeB­SD fea­tures. In case some­one has a look, please send an email to emulation@FreeBSD.org.

Share/Save

New Cen­tOS linux_base for test­ing soonish

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 near­ly usable to include into the Ports Col­lec­tion (the SRPMs need to be added, but that can be done with­in some minutes).

When FreeB­SD 8.3 is released and the Ports Col­lec­tion open for sweep­ing com­mits again, I will ask port­m­gr 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 need­ed to com­plete­ly 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­port­ed FreeB­SD releases.

Atten­tion: Any­one installing the port from the PR should be aware that using it is a high­ly exper­i­men­tal task. You need to change the lin­ux­u­la­tor to imper­son­ate him­self as a lin­ux 2.6.18 ker­nel (described in the pkg-message of the port), and the code in FreeB­SD 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­port­ed syscalls. Reports to emulation@FreeBSD.org please, not here on the webpage.

Share/Save

Sta­t­ic DTrace probes for the lin­ux­u­la­tor updated

I got a lit­tle bit of time to update my 3 year old work of adding sta­t­ic DTrace probes to the linuxulator.

The changes are not in HEAD, but in my linuxulator-dtrace branch. The revi­sion to have a look at is r230910. Includ­ed are some DTrace scripts:

  • script to check inter­nal locks
  • script to trace futexes
  • script to gen­er­ate stats for DTracified lin­ux­u­la­tor parts
  • script to check for errors: 
    • emu­la­tion errors (unsup­port­ed stuff, unknown stuff, …)
    • ker­nel errors (resource shortage, …)
    • pro­gram­ming errors (errors which can hap­pen if some­one made a mis­take, but should not happen)

The programming-error checks give hints about user­land pro­gram­ming errors respec­tive­ly a hint about the rea­son of error return val­ues due to resource short­age or maybe a wrong com­bi­na­tion of para­me­ters. An exam­ple error mes­sage for this case is “Appli­ca­tion %s issued a sysctl which failed the length restrictions.\nThe length passed is %d, the min length sup­port­ed is 1 and the max length sup­port­ed is %d.\n”.

The stats-script (tai­lored spe­cial­ly to the lin­ux­u­la­tor, but this can eas­i­ly be extend­ed to the rest of the ker­nel) can report about:

  • num­ber of calls to a ker­nel func­tion per exe­cutable bina­ry (not per PID!): allows to see where an opti­miza­tion would be ben­e­fi­cial for a giv­en application
  • graph of CPU time spend in ker­nel func­tions per exe­cutable bina­ry: togeth­er with the num­ber of calls to this func­tion this allows to deter­mine if a ker­nel opti­miza­tion would be ben­e­fi­cial / is pos­si­ble for a giv­en application
  • graph of longest run­ning (CPU-time!) ker­nel func­tion in total
  • tim­ing sta­tis­tics for the emul_lock
  • graph of longest held (CPU-time!) locks

Unfor­tu­nate­ly this can not be com­mit­ted to HEAD as-is. The DTrace SDT provider can not han­dle probes which are added to the ker­nel after the SDT provider is already loaded. This means that you either have to com­pile the lin­ux­u­la­tor sta­t­i­cal­ly into the ker­nel, or you have to load the SDT ker­nel mod­ule after the lin­ux­u­la­tor mod­ule is loaded. If you do not respect this, you get a ker­nel pan­ic on first access of one of the providers in the lin­ux­u­la­tor (AFAIR this includes list­ing the probes avail­able in the kernel).

Share/Save

More dri­vers avail­able in the FreeBSD-kernel doxy­gen docs

Yes­ter­day I com­mit­ted some more con­figs to gen­er­ate doxy­gen doc­u­men­ta­tion of FreeBSD-kernel dri­vers. I mechan­i­cal­ly gen­er­at­ed miss­ing con­figs for sub­di­rec­to­ries of src/sys/dev/. This means there is no depen­den­cy infor­ma­tion includ­ed in the con­figs, and as such you will not get links e.g. to the PCI doc­u­men­ta­tion, if a dri­ver calls func­tions in the PCI dri­ver (feel free to tell me about such dependencies).

If  you want to gen­er­ate the HTML or PDF ver­sion of some sub­sys­tem, just go to src/tools/kerneldoc/subsys/ an run “make” to get a list of tar­gets to build. As an exam­ple, “make dev_sound” will gen­er­ate the HTML ver­sion for the sound sys­tem, “make pdf-dev_sound” gen­er­ates the PDF ver­sion. The sound sys­tem is prob­a­bly the most “nice” exam­ple, as it includes a page with TODO items, and has even some real API docs instead of just the call-graphs and such auto­mat­i­cal­ly gen­er­at­ed information.

Some dri­vers already have (some) doxy­gen markup (I did just a quick grep for ‘/*[*!]’ to detect doxy­gen markup indi­ca­tors, no idea about the cov­er­age or qual­i­ty), namely:

There is more doc­u­men­ta­tion than only for those dri­vers, I just list­ed those as there are at least parts of doxy­gen doc­u­men­ta­tion inside.

Share/Save

X11 in a jail with NVidia hardware

Just before christ­mas I decid­ed I will spend the “immense” amount of 40 EUR for a graph­ic card for a sys­tem which was with­out one. The sys­tem is sup­posed to replace my dying home-server. I already moved every­thing, except my Desktop-in-a-Jail (actu­al­ly it is my home-cinema-jail).

The old sys­tem had a Radeon 9200SE, and it was enough for what I used it for. Now… for a few bucks you can get a lot more horse­pow­er today. After look­ing around a lit­tle bit I decid­ed to buy a NVidia card. I made this deci­sion because it looks like I can get bet­ter dri­ver sup­port for it. So I got a GeForce GT 520 with 1 GB of RAM (I doubt I will be able to use that much RAM) and with­out a fan.

With the Radeon 9200SE I was not able to get the 3D stuff acti­vat­ed (at least in the jail, I did not try with­out), Xorg com­plains about a miss­ing agp­gart mod­ule but I have AGP in the ker­nel (no /dev/agpgart out­side the jail). I did not spend time to inves­ti­gate this, as the main pur­pose – play­ing movies – worked. Now with the NVidia card I decid­ed to give the 3D part a try again.

After adding the NVidia device entries to the jail, and a lit­tle bit of fight­ing with the Xorg-HAL inter­ac­tion, I got a work­ing desk­top. The biggest prob­lem to ver­i­fy that 3D is work­ing was, that I did not had xdri­in­fo installed. After installing it, I noticed that it does not work with the NVidia dri­ver.  🙁  Next stop nvidia-settings: runs great, dis­plays a nice FreeBSD+NVidia logo, and … tells me that OpenGL is con­fig­ured. Hmmm… OK, but I want to see it!

As I decid­ed to switch from Gnome to KDE 4 at  the same time (I was using KDE when it was at V 0.x, switched to Gnome as it looked nicer to me, and now I switch back after read­ing all the stuff in the net that KDE 4 is “bet­ter” than Gnome 3), I was a lit­tle bit out of knowl­edge how to see the 3D stuff in action. So I quick­ly went to the set­tings and searched for some­thing which looks like it may use 3D. To my sur­prise, it was already using 3D stuff. Nice. I ful­ly real­ized how nice, when play­ing a video and using Alt-Tab to switch win­dows: the video was play­ing full speed scaled down in the window-switcher-thumbnail-view.

That was too easy. I am hap­py about it.

Now that I have a work­ing set­up of X11-in-a-jail for Radeon and GeForce cards, I want to cleanup my changes to the ker­nel and the con­fig files (devfs.rules) and have a look to get this com­mit­ted. A big part of this work is prob­a­bly writ­ing doc­u­men­ta­tion (most prob­a­bly in the wiki).

I still want to see some fan­cy 3D stuff now. I tried to install x11-clocks/glclock, but the build fails with an unde­fined ref­er­ence to ‘glPoly­gonOff­se­tEXT’. 🙁 Any rec­om­men­da­tion for a fan­cy 3D dis­play? My pri­or­i­ty is on “fancy/nice” with as less vio­lence as pos­si­ble. Most prob­a­bly I will look at it once and then dein­stall it again, so it should be avail­able in the Ports Col­lec­tion (or includ­ed in KDE 4).

Share/Save