Tag: emulation

Lin­ux­u­la­tor D‑Trace probes com­mit­ted to current

A while ago I com­mit­ted the lin­ux­u­la­tor D‑Trace probes I talked about ear­li­er. I wait­ed 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­ous­ly bad crept in.

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

Share/Save

Video4Linux sup­port in FreeBSD

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 head­er from lin­ux. We have the per­mis­sion to use it, it is not licensed via GPL. This means we can use it in FreeB­SD 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 FreeB­SD native devices which pro­vide a v4l inter­face (e.g. multimedia/pwcbsd) from lin­ux programs.

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 head­er 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 FreeB­SD native dri­vers (I do not know any FreeB­SD dri­ver which pro­vides a v4l2 inter­face) , just tell me and I import the v4l2 head­er into FreeBSD.

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

Regard­ing the code which is in FreeB­SD ATM: it is not com­plete­ly fin­ished yet (some clip­ping relat­ed stuff is being worked on), but the not fin­ished part can not even be test­ed, as we do not know about a FreeB­SD 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 like­ly I will do a MFC soon­er than later.

Share/Save

Fix for the show­stop­per bug in the linuxulator

I got time yes­ter­day to test acrore­ad with the patch from Intron/Kostik and … Yeah! I was not able to crash acrore­ad 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­ful­ly, 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).

Share/Save

Progress in the linuxulator

On of the major show­stop­per bugs in the lin­ux 2.6 emu­la­tion is that acrore­ad does not work. Now we have patch­es (proof of con­cept by Intron, refined patch by Kib) for it. I did­n’t had time to test it yet (mind you, every­one else is not able to run acrore­ad 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­er­al ways of killing it with 2.6).

If every­thing goes well and no oth­er 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­cial­ly impor­tant as the Fedo­ra Lega­cy project announced that they will aban­don sup­port for FC4. FC5+ is not able to run on a 2.4 kernel.

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. 😛

Share/Save

Short sta­tus: RealPlay­er, Sound, Linux, …

I’m busy with non-FreeBSD relat­ed stuff since a while, so there’s not much to say.

RealPlay­er: Shaun, the FreeB­SD main­tain­er of the helix­play­er port, promised to pol­ish up a patch­set when he gets time to port helix­play­er to a more recent ver­sion and send it to the cor­re­spond­ing helix com­mu­ni­ty (request­ed by some peo­ple at Real after show­ing them the patch­es via cvsweb). Their review and inte­gra­tion of this stuff will help in get­ting a RealPlay­er bina­ry from Real.

Sound: The work of Ariff (and every oth­er con­trib­u­tor) in the HDA area seems to be very appre­ci­at­ed. There are aven voic­es 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…

Lin­ux: A lot of progress hap­pened here. The long­stand­ing major bug on amd64 is fixed and MFCed (thanks to kib!), so we final­ly got some results for the amd64 runs of the LTP test­cas­es (now col­or cod­ed 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 did­n’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 togeth­er with a move to LOCALBASE (includ­ing the plu­g­in ports) avail­able, but I have to wait until the ports-slush is lifted.

Share/Save