I committed the v4l2 support into the linuxulator (in 9–current). Part of this was the import of the v4l2 header from linux. We have the permission to use it (like the v4l one), 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 v4l2 interface in GENERIC).
The code I committed is “just” the glue-code which allows to use FreeBSD native devices which provide a v4l2 interface (e.g. multimedia/pwcbsd or multimedia/webcamd) from linux programs.
Thanks to nox@ for writing the glue code.
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.
Since my call for testing the extended linuxulator in FreeBSD–current we got not much negative responses. Ping doesn’t work on the linux side (fixed in p4), ordinary network connections (e.g. downloading some stuff) works fine. There seems to be a deadlock on SMP systems when compiling a lot of stuff in parallel (e.g. using emerge in a gentoo–chroot with MAKEFLAGS=-j4), this is being under investigation by Roman. Compiling stuff serially on an UP system works just fine so far.
I’m wondering if the lack of responses means that everything is running just fine, or that nobody is giving it a try. So far the daily use of linux programs (acroread, linux-firefox, …) with 2.6.16 compatibility seems to just work fine on UP and SMP systems and currently I don’t see a reason to not switch the default in i386 in a week.
Jung-uk Kim is working on the linux-TLS on amd64 part. ATM he is chasing bugs. It looks we can get feature parity 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 committed most of Romans work in the linuxolator to current. The new syscalls aren’t used until you run
to switch back (after exiting all linux programs) you just have to run
But you have to do this on i386. Amd64 support is not complete (and besides this, amd64 is still broken and nobody provided the neccessary debugging info to jhb@).
There are some known problems with osrelease=2.6.16, e.g., problems with futexes (visible in acroread, realplay and skype), but some programs already run without obvious problems (linux-firefox, linux-opera).
Any reports about new problems to netchild@ and rdivacky@ please. Reviews, debugging info and patches are welcome too.