I agree with most of what all of you are saying.
Where possible, I designed the V4L2 videodev to insulate the V4L2
drivers from kernel details like struct file and struct file_operations
that can change with new versions. When your driver is not in the kernel
and needs to work with many kernel versions, that is a plus. If V4L2 is
in the kernel, then the need diminishes. Still, if videodev can hold
code that would otherwise need to be duplicated in the drivers, then why
not?
I'm not sure what all the issues are with driver registration, but it
seems to me a good idea to keep separate registration functions for V4L2
and v4l drivers so videodev knows which is which in case it becomes
necessary. We can tweak the v4l and V4L2 registration if need be.
Moving the v4l compatibility out to a separate, optional module is a
great idea. To make it optional, all you have to do is, when the compat.
module loads, have it pass pointers to its helper functions to videodev
by a registration function in videodev.
Michael Hunold wrote:
> Do you really mean to move the responsibility of being
> v4l-backward compatible deep down to a v4l2 driver, e.g.
> looking at the ioctls, formats and do the translation
> by calling helper functions?
The burden seems small. As Gerd pointed out, it reduces to:
v4l2_ioctl(...) {
switch (cmd) {
default: return v4l2_translate_ioctl(...);
...
}
}
Maybe some code in mmap() too.
But I don't think that would be necessary, would it? Control always has
to pass through the videodev ioctl() hook, so it could be done there?
Alan Cox wrote:
> It would to think much more about putting the bits of V4L2
> that are missing or better into V4L not about two interfaces.
> That way lies pain.
I don't think one can "put bits of V4L2 that are better into V4L" and
end up with a decent, coherent interface. V4L2 is arranged differently.
The main reason applications are still being written for and supporting
v4l is because it's in the standard kernel and V4L2 is not. If V4L2 is
in the kernel, that reason goes away. Once V4L2 is in the kernel, v4l
support can later be made optonal, and eventually be phased out.
> > What is the status of the other v4l2 API's? codec? effects? ...
>
> Then these should left out too IMHO. There is no point in having
> a unused API in the kernel.
Agree.
Bill.
