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.

Yes­ter­day I com­mit­ted the v4l sup­port into the lin­ux­u­la­tor (in 9-current). Part of this was the import of the v4l header from linux. We have the per­mis­sion to use it, it is not licensed via GPL. This means we can use it in FreeBSD native dri­vers, and they are even allowed to be com­piled into GENERIC (but I doubt we have a dri­ver which could pro­vide the v4l inter­face in GENERIC).

The code I com­mit­ted is “just” the glue-code which allows to use FreeBSD native devices which pro­vide a v4l inter­face (e.g. multimedia/pwcbsd) from linux pro­grams.

If some­one is will­ing to write the glue-code for the v4l2 inter­face please con­tact me. We have the per­mis­sion to use the v4l2 header too, we just need some­one doing the coding.

In a sim­i­lar way, if some­one is will­ing to add v4l2 inter­face sup­port to FreeBSD native dri­vers (I do not know any FreeBSD dri­ver which pro­vides a v4l2 inter­face) , just tell me and I import the v4l2 header into FreeBSD.

And if some­one wants to add v4l sup­port to FreeBSD native dri­vers but does not know where to start, feel free to con­tact me too.

Regard­ing the code which is in FreeBSD ATM: it is not com­pletely fin­ished yet (some clip­ping related stuff is being worked on), but the not fin­ished part can not even be tested, as we do not know about a FreeBSD device which pro­vides this functionality.

There is no MFC planned yet, but the more suc­cess sto­ries and test sce­nar­ios are being told about on the emu­la­tion or mul­ti­me­dia mail­inglists, the more likely I will do a MFC sooner than later.

I got time yes­ter­day to test acroread with the patch from Intron/Kostik and … Yeah! I was not able to crash acroread in the 2.6.16 emu­la­tion! Great! Request for wide­spread test­ing soon?!?

Now we just have to deter­mine if we have to care about the lock­ing (I don’t know if kib@ already asked jhb@ about it) and the race con­di­tion. In case the user­land exhibits very very bad pro­gram­ming and is using the FD before open() returns suc­cess­fully, the pro­gram could read data. This can only hap­pen if the pro­gram has the right per­mis­sion to this data (the open is sup­posed to fail in this case not because of access restric­tions, but because of e.g., the wrong file type).

On of the major show­stop­per bugs in the linux 2.6 emu­la­tion is that acroread does not work. Now we have patches (proof of con­cept by Intron, refined patch by Kib) for it. I didn’t had time to test it yet (mind you, every­one else is not able to run acroread with 2.6, I’m able to run it at least with some files or no file at all), but I want to do an exten­sive test (I know sev­eral ways of killing it with 2.6).

If every­thing goes well and no other show­stop­per bug appears, we may be able to request more exten­sive test­ing of the 2.6 emu­la­tion, at least on i386. First this should be done by ask­ing peo­ple to switch, and maybe after a week by switch­ing the default emu­la­tion to 2.6 in –cur­rent (at least for a while).

This is spe­cially impor­tant as the Fedora Legacy project announced that they will aban­don sup­port for FC4. FC5+ is not able to run on a 2.4 ker­nel.

And while I’m at it: I sub­mit­ted the sta­tus report for the lin­ux­u­la­tor. It con­tains some nice sta­tis­tic about the num­ber of fixed bugs (com­par­ing 6.2 and –cur­rent). No, I will not tell you in advance, you have to wait some days until the report shows up.

I’m busy with non–FreeBSD related stuff since a while, so there’s not much to say.

RealPlayer: Shaun, the FreeBSD main­tainer of the helix­player port, promised to pol­ish up a patch­set when he gets time to port helix­player to a more recent ver­sion and send it to the cor­re­spond­ing helix com­mu­nity (requested by some peo­ple at Real after show­ing them the patches via cvsweb). Their review and inte­gra­tion of this stuff will help in get­ting a RealPlayer binary from Real.

Sound: The work of Ariff (and every other con­trib­u­tor) in the HDA area seems to be very appre­ci­ated. There are aven voices ask­ing for a MFC. I don’t think we will get it for 6.2. It’s too late in the release process and Ariff seems to be busy.

Sound2: Ryan com­mit­ted a fix to P4 which should pro­vide some miss­ing stuff to some break­ing ports. If some­one has time to com­mit it…

Linux: A lot of progress hap­pened here. The long­stand­ing major bug on amd64 is fixed and MFCed (thanks to kib!), so we finally got some results for the amd64 runs of the LTP test­cases (now color coded to spot prob­lems much faster). The sta­tus of the sta­ble run is already on the wiki page (but this is with­out the MFC). Runs on cur­rent (2.4.2 and 2.6.16 based emu­la­tion) and sta­ble after the MFC where already done, but I didn’t got time to wiki-fy their sta­tus yet.

Ports: I already have an update for my sylpheed-claws port to 2.6.0 together with a move to LOCALBASE (includ­ing the plu­gin ports) avail­able, but I have to wait until the ports-slush is lifted.