OK, the discussion in response to my RFC was very enlightening. Based on that I decided on the following roadmap: 1) Remove the sysfs code from the framework for the time being. It is not necessary for the first version. What I would like to do is to take another good look at the data structures and code to see if I can organize it in such a way that adding debugfs and/or sysfs in the future would be very easy to do. I also want to make sure that 'remap' functionality would be easy to add later. I strongly suspect that we will need that for certain corner cases as Andy described. 2) Verify that uvc can work with this. The UVC driver can dynamically add new controls for UVC webcams. It should work with the framework but this needs to be verified. This will take some time since both Laurent and myself are busy for the next two weeks. 3) If all is OK, then I can post a patch series for the basic framework. 4) Once merged the work can begin on converting bridge and subdev drivers. 5) Further discuss sysfs/debugfs support. Support for sysfs (and possibly debugfs) will depend on the event patches being merged (as that introduces struct v4l2_fh) and the proposed pre/post hooks in ioctl_ops. Pre/post hooks in turn depend on improve core support for v4l2_priority (which in turn depends on the struct v4l2_fh). It's all pretty trivial code, but it is needed to provide a 'fixed' control path that drivers can rely on. No matter whether the driver is approached via an ioctl, sysfs or debugfs, from the point of view of the driver it should all look like an ioctl. That way the driver doesn't have to deal with multiple points of entry. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
