> > receive a kernel pointer. With file_operations->ioctl() this obviously > > doesn't work any more, because that function is expected to handle > > userspace copying itself. We'll have to pass a callback function to > > translate_ioctl() somehow. Either directly as argument, or somewhere > > in a struct. > > I don't know... IMHO this is starting to not look very clean anymore. > How about simply testing if it is a v4l1 or v4l2 device, and if it is > v4l2 do the conversion?? Where do you want to check? With the patch mailed the videodev module doesn't see anything but the open() syscall (if the driver uses fops), all other syscalls are routed directly to the driver. It swaps the file handle's struct file_operations in video_open(). > OK, didn't think of that one. Is there a way for a module to find out > if a specific symbol is being exported by another module (i.e. can a > driver look for a translate_ioctl function in module v4l1-compat which > has been previously loaded)? Simply use it (like bttv uses videodev_register for example), the other module will be loaded automagically by module dependences. Or do you mean something else? > Yes, it will still work with the traditional major/minor scheme, but if > you add a string field as well, then v4l2 devices don't have to use > v4l1's minor number ranges. I can't see any advantages you get ... > > Add a type2 field? > I suppose, then a driver could register both v4l1 and v4l2 capabilities > without any problems. ... which we need to handle both v4l + v4l2 with the same minor number. > > Ack. > > ??? Why "Ack." ? == I agree. network slang :-) > The thing is S_FMT and G_FMT are used for setting other formats too. > You can't remove S_FMT and G_FMT, so you gain nothing by forcing v4l2 > drivers to interpret VIDIOCGVBIFMT, etc. instead. v4l2 drivers are supported to be backward compatible to v4l, so they have to interpret VIDIOCGVBIFMT anyway. And I can't see any advantages v4l2 has here, so why support two different ways to do exactly the same? Gerd
