> I'm sorry to say this, and I've thought for a while if I even should > mention this, but this is how I feel about it. In stead of fixing the > problems that are there for V4L1, or making a commitment of getting > V4L2 into the kernel and drivers, you introduce changes for an API > that I consider out-of-date (though in widespread use) and work for > us who write the drivers. The videodev changes are not related at all to v4l1 vs. v4l2 API. They just fix some design bugs. videodev.o doesn't care much about which API is implemented by a specific driver, it only takes care about handing out the minor numbers to the drivers. The point of using fops directly is to give drivers the full control about whatever they need. They have struct file*, they can use file->private_data for example. This allows sane implementations of multiple opens because you can keep the filehandles apart. You can put a pointer to your drivers data into file->private_data, which in makes it possible to unregister() while the device is opened, which in turn fixes some nasty races for hot-pluggable stuff like usb. And if something changes in struct file_operations, we don't have to update struct video_device every time ... > My main complaint is that now I have to keep track of 3 development > threads: the 2.4 kernel, the 2.5 kernel which literally changes memory > subsystem every release, and this V4L1.1 interface. No, the 2.5 stuff should work on 2.4 too. At least that is the plan, because I know that maintaining many trees is a real pain. > Oh yes, for the Question: when do you think this will make it into > 2.5 (if it hasn't already)? videodev patch 2.5.7-pre1, batch of driver patches 2.5.7-pre2. marcelos bk tree already has the 2.4 videodev patch (with some small buglets left, but they should be fixed until 2.2.19-final). vmalloc_to_page() backport is in there too btw, thus the driver with 2.5.x memory subsystem adaptions should build on 2.4 starting with the next pre patch. > > As for abandoning 2.4 because of V4L2, you probably won't have to do > > that completely. The V4L2 "videodevX" driver works with 2.2 and 2.4, and > > supports both V4L1 and V4L2 drivers and apps. videodevX in kernel isn't going to happen. There is no point in having the device registering twice depending on which API a driver supports, because videodev.o doesn't need to know. And the limitations the old videodev.o module had (like not giving struct file* to the drivers) are fixed by using fops directly. Plan for v4l2: The v4l2-common module will go in, the v4l1-compat module will go in, and also the header file with all the structs for v4l2. But before sendining stuff to Linus I want to have some small API issues fixed, like adding the mjpeg ioctl for the zoran people. I'm also not sure yet how to call the v4l_compat_translate_ioctl(), whenever to hook that into the video_generic_ioctl function (like current patches do) or expect drivers to call it if they want the v4l1-compat module handle v4l1 ioctls. As usual: patches are available from http://bytesex.org/patches/ ... Gerd -- #include </dev/tty>
