I com­mit­ted the v4l2 sup­port into the lin­ux­u­la­tor (in 9–cur­rent). Part of this was the import of the v4l2 header from linux. We have the per­mis­sion to use it (like the v4l one), 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 v4l2 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 v4l2 inter­face (e.g. multimedia/pwcbsd or multimedia/webcamd) from linux pro­grams.

Thanks to nox@ for writ­ing the glue code.

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.

Since my call for test­ing the extended lin­ux­u­la­tor in FreeBSD-cur­rent we got not much neg­a­tive responses. Ping doesn’t work on the linux side (fixed in p4), ordi­nary net­work con­nec­tions (e.g. down­load­ing some stuff) works fine. There seems to be a dead­lock on SMP sys­tems when com­pil­ing a lot of stuff in par­al­lel (e.g. using emerge in a gentoo-chroot with MAKEFLAGS=-j4), this is being under inves­ti­ga­tion by Roman. Com­pil­ing stuff seri­ally on an UP sys­tem works just fine so far.

I’m won­der­ing if the lack of responses means that every­thing is run­ning just fine, or that nobody is giv­ing it a try. So far the daily use of linux pro­grams (acroread, linux-firefox, …) with 2.6.16 com­pat­i­bil­ity seems to just work fine on UP and SMP sys­tems and cur­rently I don’t see a rea­son to not switch the default in i386 in a week.

Jung-uk Kim is work­ing on the linux-TLS on amd64 part. ATM he is chas­ing bugs. It looks we can get fea­ture par­ity between i386/linux and amd64/linux32 soon.

Intron did send in a patch for the linux-aio stuff. Now I just need to get time to have a look at it.

I com­mit­ted most of Romans work in the lin­ux­o­la­tor to cur­rent. The new syscalls aren’t used until you run

sysctl com­pat.linux.osrelease=2.6.16

to switch back (after exit­ing all linux pro­grams) you just have to run

sysctl compat.linux.osrelease=2.4.2

But you have to do this on i386. Amd64 sup­port is not com­plete (and besides this, amd64 is still bro­ken and nobody pro­vided the nec­ces­sary debug­ging info to jhb@).

There are some known prob­lems with osrelease=2.6.16, e.g., prob­lems with futexes (vis­i­ble in acroread, realplay and skype), but some pro­grams already run with­out obvi­ous prob­lems (linux–fire­fox, linux-opera).

Any reports about new prob­lems to netchild@ and rdivacky@ please. Reviews, debug­ging info and patches are wel­come too.