Em 27-06-2011 13:14, Arnd Bergmann escreveu: > On Monday 27 June 2011, Mauro Carvalho Chehab wrote: >>> The point is that the spec can easily be improved to make such 'NOP' >>> operations >>> explicit, or to require that if a capability is present, then the >>> corresponding >>> ioctl(s) must also be present. Things like that are easy to verify as well >>> with >>> v4l2-compliance. >> >> We currently have more than 64 ioctl's. Adding a capability bit for each >> doesn't >> seem the right thing to do. Ok, some could be grouped, but, even so, there >> are >> drivers that implement the VIDIOC_G, but doesn't implement the corresponding >> VIDIO_S. >> So, I think we don't have enough available bits for doing that. > > It shouldn't be too hard to do an ioctl command that returns a le_bitmask > with the > ioctl command number as an index (0 to 91, currently), and the bit set for > each > command that has the corresponding v4l2_ioctl_ops member filled for the > device. > That would be an obvious way to query the operations, but I don't know if it's > useful.
Tricks like that could be done, but that would not be consistent with other subsystems that use -ENOTTY for such purpose. Also, to avoid having magic numbers, this will end by adding a somewhat complex logic at userspace (or having some sort of macro exported together with videodev2.h), in order to associate a V4L2 ioctl with the corresponding le_bitmask bit. Also, 91 ioctls seems a complex-enough API to me. We should avoid adding more stuff there without very good reasons. In any case, we should also double check how this is done by the other API's used at the media subsystem, and try to do the same there (lirc, Media Controller and DVB APIs). My intention is to split the error handling changes from the original series that remove the linux/version.h, and spend some time preparing a new RFC about that, trying to cover all the API's defined under drivers/media. One idea could be to postpone a decision about it, and discuss this topic further during the media workshop at the KS/2011. Thanks, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
