On Fri, Apr 2, 2010 at 1:43 PM, Manu Abraham <abraham.manu@xxxxxxxxx> wrote: > On Thu, Apr 1, 2010 at 10:24 PM, Mauro Carvalho Chehab > <mchehab@xxxxxxxxxx> wrote: > >> You'll have issues also with -alsa and -dvb parts that are present on the drivers. >> >> Also, drivers like cx88 have another PCI device for mpeg-encoded streams. It behaves >> like two separate drivers (each with its own bind code at V4L core), but, as there's >> just one PCI bridge, and just one analog video decoder/analog audio decoder, the lock >> should cross between the different drivers. >> >> So, binding videobuf to v4l2_device won't solve the issue with most videobuf-aware drivers, >> nor the lock will work as expected, at least with most of the devices. >> >> Also, although this is not a real problem, your lock is too pedantic: it is >> blocking access to several ioctl's that don't need to be locked. For example, there are >> several ioctl's that just returns static: information: capabilities, supported video standards, >> etc. There are even some cases where dynamic ioctl's are welcome, like accepting QBUF/DQBUF >> without locking (or with a minimum lock), to allow different threads to handle the buffers. >> >> The big issue I see with this approach is that developers will become lazy on checking >> the locks inside the drivers: they'll just apply the flag and trust that all of their >> locking troubles were magically solved by the core. >> >> Maybe a better alternative would be to pass to the V4L2 core, optionally, some lock, >> used internally on the driver. This approach will still be pedantic, as all ioctls will >> keep being serialized, but at least the driver will need to explicitly handle the lock, >> and the same lock can be used on other parts of the driver. > > > IMO, A framework shouldn't lock. Why ? > > Different devices require different locking schemes, each and every > device require it in different ways. Some drivers might not even > require it, since they may be able to handle different systems > asynchronously. > > Locking and such device management, will be known to the driver alone > and not to any framework. While, this may benefit some few devices the > other set of devices will eventually be broken. Hello Manu, The argument I am trying to make is that there are numerous cases where you should not be able to use both a particular DVB and V4L device at the same time. The implementation of such locking should be handled by the v4l-dvb core, but the definition of the relationships dictating which devices cannot be used in parallel is still the responsibility of the driver. This way, a bridge driver can say "this DVB device cannot be used at the same time as this V4L device" but the actual enforcement of the locking is done in the core. For cases where the devices can be used in parallel, the bridge driver doesn't have to do anything. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
