On Wed, Apr 11, 2001 at 08:09:53PM -0700, Bill Dirks wrote:
> 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.
If they change, they usually change for a reason. That change might be
important for the driver, so I don't think it is good to hide that within
the videodev layer.
> 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?
That code I'd like to see in the compatibility/helper/... module.
> 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.
Why register? The driver can simply call the functions in the helper
module.
> 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?
It has not. If video_open() swaps the struct file_operations pointer in
the file handle (look at the patch I've mailed), videodev will _not_ see
ioctl calls from the application.
> 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.
I agree. Nearly all ioctls work different. I think the only ones which
are completely unchanged are VIDIOC_G_FREQ/VIDIOC_S_FREQ. Anything else
has changed alot (like the mmap() capture interface) or at least a little
bit (missing fields added / moved some to the right place / ...).
> 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.
v4l has been _the_ interface for years. And it probably takes at least
one more year until v4l2 shows up in a stable kernel (2.6). I don't
think we can phase out v4l1 ...
Gerd
