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 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 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 am in the process of prepar­ing the import of code which makes v4l devices usable in the lin­ux­u­la­tor. Basi­cally this means you can use your web­cam in skype (tested by the sub­mit­ter of the patch on amd64).

This is not a “apply patch and com­mit” thing, because the orig­i­nal videodev.h (with some mod­i­fi­ca­tions) is used. I was seek­ing the OK from core@ for this. As there is no license in the header, and the orig­i­nal author (Alan Cox, the linux one, not our FreeBSD one) gave per­mis­sions to use it, core@ is OK with the import.

I intent to do a ven­dor import of the linux header (pre­pared today, together with some readme which explains where it comes from and some stuff to show that we are on the safe side regard­ing legal stuff), and then I want to copy this over to the lin­ux­u­la­tor as linux_videodev.h and com­mit the patch (prob­a­bly a lit­tle bit mod­i­fied in a few places). My plan is to com­mit it this week. Peo­ple which already want to play around with it now can have a look at the emu­la­tion mail­inglist, a link to the patch is posted there.

With the header being in a ven­dor branch, inter­ested peo­ple could then start to sub­mit new BSD licensed dri­vers or mod­ify exist­ing dri­vers which make use of the v4l inter­face, but I let the import of the header into the FreeBSD include direc­tory up to the per­son which wants to com­mit the first native FreeBSD-v4l support.

When such native FreeBSD-v4l sup­port is com­mit­ted, the lin­ux­u­la­tor code needs to be revised.

Today I fixed 3 linux ports (con­vert­ing to the “new” world order) to not use RPM directly (the right thing is to use rpm2cpio, and bsd.linux-rpm.mk pro­vides some nice stuff to han­dle this).

In the last week I fixed some stuff in the lin­ux­u­la­tor–MFC patch. It should now com­pile on amd64 and i386 with­out prob­lems (at least the code which I have locally). There’s one (strange) panic report which I want to ana­lyze and fix (if it is lin­ux­u­la­tor related) with Roman before I update the patch on my site.

I had a look at some USB PRs and wrote a list of those with patches to Warner (as he is work­ing on USB stuff cur­rently). I also cat­e­go­rized them (easy, not easy, maybe already fixed, …). The easy ones he han­dled already, for the rest I don’t know his cur­rent plans.

Regard­ing lin­ux­u­la­tor stuff I’m work­ing on a MFC patch (no TLS, no futexes). As I don’t have a –sta­ble box I need some help test­ing it before I can com­mit it. I only com­pile tested this on –cur­rent with the new gcc 4.2. What I need is:

• test­ing on i386, amd64 (if I for­got some­thing, it may panic your system)
• “make uni­verse” test (you have to grep all the logs for “Error 1″ and inves­ti­gate the error if there’s one)
• LTP test run, see the wiki for more (best would be a diff of the logs in the result direc­tory of no-patch/patch runs)
• nor­mal linux appli­ca­tion use-tests

What the patch pro­vides is:

• mmap fixes
• fix mem­leaks
• add mprotect/iopl/lstat/ftruncate/statfs64/timer_*/mq_*
• more errno value mapping
• don’t limit num­ber of syscalls to 255
• allow to exec libs
• ioctl TIOCGPTN
• han­dle more socket options
• de-COMPAT_43-ify
• add dummy syscalls so that we know what is needed (reports from users)
• style(9)
• lin­procfs enhancements

The lin­ux­u­la­tor is synced on amd64 with i386 (since a while). This means TLS is work­ing now and we have the same (a lit­tle bit buggy) futexes.

Roman is slowly work­ing on the *at() com­mands. He also applied for the GSoC this year again. Kib is will­ing to men­tor (in case Roman gets a free seat in the SoC). I rejected the men­tor­ing posi­tion this time, as I don’t know if I will have enough time this sum­mer, but I hope I will be around.