Weekly Edition
Return to the Kernel page
| |||||||||||||
The end for Video4Linux1
The Video4Linux1 (V4L1) ABI is deprecated, and has been for a long time; it
was ostensibly replaced by Video4Linux2 in the 2.5 development series.
But, as has been discovered many times, an ABI is a hard thing to get rid
of. So the kernel still supports V4L1 applications; indeed, there are
still V4L1-only drivers in current kernels. That situation has persisted
for a long time, but it may now be coming to an end.
Hans Verkuil has posted a multi-stage proposal for the removal of V4L1 from the kernel. The first phase involves the conversion of the remaining V4L1 drivers - of which there are several - to the newer ABI. Some of those drivers have since been supplanted by GSPCA and may just be deleted outright. All told, this is a bit of much-needed janitorial work. Phase 2 may be a bit more controversial, though, in that it calls for the removal of the V4L1 compatibility layer in the kernel. This code allows V4L1 applications to work with V4L2 drivers - most of the time. It was an important bit of backward compatibility support, but it has also helped to delay the updating of a number of old V4L1 applications. Given that these applications do still exist (many distributions still ship xawtv, for example), it might be a bit surprising that this layer is slated for removal, perhaps as soon as 2.6.36. There are problems with the compatibility layer. It cannot provide access to much of the functionality of contemporary hardware and drivers, it cannot always do the right thing in response to application requests, and it has been a long time since anybody had any interest in maintaining this code. So the V4L developers would like to push it out into user space, and into the libv4l1 library in particular. Supporting old applications would then be a matter of a quick edit (replacing ioctl() calls with v4l1_ioctl(), for example) and a rebuild against the library. Some old applications may be pulled into the V4L project, since their original maintainers have almost certainly long since lost interest. It's not a perfect solution; old, binary applications will cease to work on newer kernels. It is an ABI break, plain and simple, and it is possible that there will be enough of an uproar to prevent this change from happening in the end. But it may also be that nobody really cares about running binary V4L1 applications on new kernels, and that it is truly time for this old interface to pass into history. (Log in to post comments)
The end for Video4Linux1 Posted Mar 25, 2010 9:53 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
Personally I welcome a certain tempering of the "binary compatibility for ever" line. There
are so many other reasons why it will be hard to get e.g. a binary build for Linux 0.99 to run on a current system that keeping the kernel binary interfaces that stable seems a bit silly. If you really need to run that sort of binary you can still go for an emulation or virtualisation solution of one shape or another, and there are other places compatibility layers can be kept than inside the security-critical kernel space.
The end for Video4Linux1 Posted Mar 26, 2010 16:36 UTC (Fri) by jwarnica (subscriber, #27492) [Link]
The theory should also be flexible, and change as you get to more and more obscure things. And take into consideration the ecosystem of what actually uses that feature.
V4L, almost by definition, deals with unusual and possibly obscure hardware. The usecases might neatly fall into: stable systems with old hardware that never changes, is never upgraded, etc. And: bleeding edge systems with new and cool hardware, tweaked to the Nth degree by some geek giant.
At the very least: V4L deals with hardware. Old hardware? Old kernel. New hardware? New kernel. That seems fair and reasonable to me.
The end for Video4Linux1 Posted Mar 25, 2010 10:12 UTC (Thu) by farnz (guest, #17727) [Link] Note that (AIUI) libv4l1 also comes with an LD_PRELOAD shim, that intercepts open, ioctl, mmap et al, passes through non-V4L usage, and calls v4l1_open etc for you. The net result is the ability to run V4L1 only applications unchanged.
The end for Video4Linux1 Posted Mar 29, 2010 18:46 UTC (Mon) by jimparis (subscriber, #38647) [Link]
Assuming it's dynamically linked. You'd need a bit more work for static binaries (eg., ptrace-based syscall interception)
Time for a new kernel major version? Posted Apr 10, 2010 14:39 UTC (Sat) by goeran (subscriber, #151) [Link]
Maybe removal of binary interfaces should be is for a major release? Name the next kernel 3.0 where this, and maybe other obsolete interfaces, are removed! New functionality is added continuously, and there will probably never be a "major" step in that sense. But cleaning out of obsolete stuff could make sense to distinguish like this?
Or at least a 2.7 series, which drops compatibility with 2.6. That would be another way to give back some meaning to the first two numbers in the kernel version number.
|
|||||||||||||