A while ago I committed the linuxulator D‑Trace probes I talked about earlier. I waited a little bit for this announcement to make sure I have not broken anything. Nobody complained so far, so I assume nothing obviously bad crept in.
The >500 probes I committed do not cover the entire linuxulator, but are a good start. Adding new ones is straight forward, if someone is interested in a junior-kernel-hacker task, this would be one. Just ask me (or ask on emulation@), and I can guide you through it.
Yesterday I committed the v4l support into the linuxulator (in 9-current). Part of this was the import of the v4l header from linux. We have the permission to use it, it is not licensed via GPL. This means we can use it in FreeBSD native drivers, and they are even allowed to be compiled into GENERIC (but I doubt we have a driver which could provide the v4l interface in GENERIC).
The code I committed is “just” the glue-code which allows to use FreeBSD native devices which provide a v4l interface (e.g. multimedia/pwcbsd) from linux programs.
If someone is willing to write the glue-code for the v4l2 interface please contact me. We have the permission to use the v4l2 header too, we just need someone doing the coding.
In a similar way, if someone is willing to add v4l2 interface support to FreeBSD native drivers (I do not know any FreeBSD driver which provides a v4l2 interface) , just tell me and I import the v4l2 header into FreeBSD.
And if someone wants to add v4l support to FreeBSD native drivers but does not know where to start, feel free to contact me too.
Regarding the code which is in FreeBSD ATM: it is not completely finished yet (some clipping related stuff is being worked on), but the not finished part can not even be tested, as we do not know about a FreeBSD device which provides this functionality.
There is no MFC planned yet, but the more success stories and test scenarios are being told about on the emulation or multimedia mailinglists, the more likely I will do a MFC sooner than later.
I got time yesterday to test acroread with the patch from Intron/Kostik and … Yeah! I was not able to crash acroread in the 2.6.16 emulation! Great! Request for widespread testing soon?!?
Now we just have to determine if we have to care about the locking (I don’t know if kib@ already asked jhb@ about it) and the race condition. In case the userland exhibits very very bad programming and is using the FD before open() returns successfully, the program could read data. This can only happen if the program has the right permission to this data (the open is supposed to fail in this case not because of access restrictions, but because of e.g., the wrong file type).
On of the major showstopper bugs in the linux 2.6 emulation is that acroread does not work. Now we have patches (proof of concept by Intron, refined patch by Kib) for it. I didn’t had time to test it yet (mind you, everyone 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 extensive test (I know several ways of killing it with 2.6).
If everything goes well and no other showstopper bug appears, we may be able to request more extensive testing of the 2.6 emulation, at least on i386. First this should be done by asking people to switch, and maybe after a week by switching the default emulation to 2.6 in -current (at least for a while).
This is specially important as the Fedora Legacy project announced that they will abandon support for FC4. FC5+ is not able to run on a 2.4 kernel.
And while I’m at it: I submitted the status report for the linuxulator. It contains some nice statistic about the number of fixed bugs (comparing 6.2 and ‑current). 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 maintainer of the helixplayer port, promised to polish up a patchset when he gets time to port helixplayer to a more recent version and send it to the corresponding helix community (requested by some people at Real after showing them the patches via cvsweb). Their review and integration of this stuff will help in getting a RealPlayer binary from Real.
Sound: The work of Ariff (and every other contributor) in the HDA area seems to be very appreciated. There are aven voices asking 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 committed a fix to P4 which should provide some missing stuff to some breaking ports. If someone has time to commit it…
Linux: A lot of progress happened here. The longstanding major bug on amd64 is fixed and MFCed (thanks to kib!), so we finally got some results for the amd64 runs of the LTP testcases (now color coded to spot problems much faster). The status of the stable run is already on the wiki page (but this is without the MFC). Runs on current (2.4.2 and 2.6.16 based emulation) and stable after the MFC where already done, but I didn’t got time to wiki-fy their status yet.
Ports: I already have an update for my sylpheed-claws port to 2.6.0 together with a move to LOCALBASE (including the plugin ports) available, but I have to wait until the ports-slush is lifted.