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

A while ago I com­mit­ted the linuxu­lat­or D-​Trace probes I talked about earli­er. 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 cov­er the en­tire linuxu­lat­or, but are a good start. Adding new ones is straight for­ward, if someone is in­ter­ested in a ju­ni­or–ker­nel–hack­er task, this would be one. Just ask me (or ask on emu­la­tion@), and I can guide you through it.

Video4Linux sup­port in FreeBSD

Yes­ter­day I com­mit­ted the v4l sup­port in­to the linuxu­lat­or (in 9–cur­rent). Part of this was the im­port of the v4l head­er from linux. We have the per­mis­sion to use it, it is not li­censed via GPL. This means we can use it in FreeBSD nat­ive drivers, and they are even al­lowed to be com­piled in­to GENERIC (but I doubt we have a driver which could provide the v4l in­ter­face in GENERIC).

The code I com­mit­ted is “just” the glue-​code which al­lows to use FreeBSD nat­ive devices which provide a v4l in­ter­face (e.g. multimedia/​pwcbsd) from linux pro­grams.

If someone is will­ing to write the glue-​code for the v4l2 in­ter­face please con­tact me. We have the per­mis­sion to use the v4l2 head­er too, we just need someone do­ing the cod­ing.

In a sim­il­ar way, if someone is will­ing to add v4l2 in­ter­face sup­port to FreeBSD nat­ive drivers (I do not know any FreeBSD driver which provides a v4l2 in­ter­face) , just tell me and I im­port the v4l2 head­er in­to FreeBSD.

And if someone wants to add v4l sup­port to FreeBSD nat­ive drivers but does not know where to start, feel free to con­tact me too.

Re­gard­ing the code which is in FreeBSD ATM: it is not com­pletely fin­ished yet (some clip­ping re­lated stuff is be­ing worked on), but the not fin­ished part can not even be tested, as we do not know about a FreeBSD device which provides this func­tion­al­ity.

There is no MFC planned yet, but the more suc­cess stor­ies and test scen­ari­os are be­ing told about on the emu­la­tion or mul­ti­me­dia mailing­lists, the more likely I will do a MFC soon­er than later.

Fix for the showstop­per bug in the linuxu­lat­or

I got time yes­ter­day to test acror­ead with the patch from In­tron/​Kostik and … Yeah! I was not able to crash acror­ead in the 2.6.16 emu­la­tion! Great! Re­quest for wide­spread test­ing soon?!?

Now we just have to de­term­ine 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 ex­hib­its very very bad pro­gram­ming and is us­ing the FD be­fore open() re­turns 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 be­cause of ac­cess re­stric­tions, but be­cause of e.g., the wrong file type).

Pro­gress in the linuxu­lat­or

On of the ma­jor showstop­per bugs in the linux 2.6 emu­la­tion is that acror­ead does not work. Now we have patches (proof of con­cept by In­tron, re­fined patch by Kib) for it. I didn’t had time to test it yet (mind you, every­one else is not able to run acror­ead 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 ex­tens­ive test (I know sev­er­al ways of killing it with 2.6).

If everything goes well and no oth­er showstop­per bug ap­pears, we may be able to re­quest more ex­tens­ive test­ing of the 2.6 emu­la­tion, at least on i386. First this should be done by ask­ing people to switch, and may­be af­ter a week by switch­ing the de­fault emu­la­tion to 2.6 in -cur­rent (at least for a while).

This is spe­cially im­port­ant as the Fe­dora Leg­acy pro­ject an­nounced 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 status re­port for the linuxu­lat­or. It con­tains some nice stat­ist­ic about the num­ber of fixed bugs (com­par­ing 6.2 and –cur­rent). No, I will not tell you in ad­vance, you have to wait some days un­til the re­port shows up. 😛

Short status: Real­Play­er, Sound, Linux, …

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

Real­Play­er: Shaun, the FreeBSD main­tain­er of the helix­play­er port, prom­ised to pol­ish up a patch­set when he gets time to port helix­play­er to a more re­cent ver­sion and send it to the cor­res­pond­ing helix com­munity (re­ques­ted by some people at Real af­ter show­ing them the patches via cvsweb). Their re­view and in­teg­ra­tion of this stuff will help in get­ting a Real­Play­er bin­ary from Real.

Sound: The work of Ar­iff (and every oth­er con­trib­ut­or) in the HDA area seems to be very ap­pre­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 re­lease pro­cess and Ar­iff seems to be busy.

Sound2: Ry­an com­mit­ted a fix to P4 which should provide some miss­ing stuff to some break­ing ports. If someone has time to com­mit it…

Linux: A lot of pro­gress happened here. The long­stand­ing ma­jor bug on amd64 is fixed and MFCed (thanks to kib!), so we fi­nally got some res­ults for the amd64 runs of the LTP test­cases (now col­or coded to spot prob­lems much faster). The status of the stable run is already on the wiki page (but this is without the MFC). Runs on cur­rent (2.4.2 and 2.6.16 based emu­la­tion) and stable af­ter the MFC where already done, but I didn’t got time to wiki-​fy their status yet.

Ports: I already have an up­date for my sylpheed-​claws port to 2.6.0 to­geth­er with a move to LOCALBASE (in­clud­ing the plu­gin ports) avail­able, but I have to wait un­til the ports–slush is lif­ted.