On Tuesday 16 November 2010, Hans Verkuil wrote: > > I think there is a misunderstanding. One V4L device (e.g. a TV capture > > card, a webcam, etc.) has one v4l2_device struct. But it can have multiple > > V4L device nodes (/dev/video0, /dev/radio0, etc.), each represented by a > > struct video_device (and I really hope I can rename that to v4l2_devnode > > soon since that's a very confusing name). > > > > You typically need to serialize between all the device nodes belonging to > > the same video hardware. A mutex in struct video_device doesn't do that, > > that just serializes access to that single device node. But a mutex in > > v4l2_device is at the right level. Ok, got it now. > A quick follow-up as I saw I didn't fully answer your question: to my > knowledge there are no per-driver data structures that need a BKL for > protection. It's definitely not something I am worried about. Good. Are you preparing a patch for a per-v4l2_device then? This sounds like the right place with your explanation. I would not put in the CONFIG_BKL switch, because I tried that for two other subsystems and got called back, but I'm not going to stop you. As for the fallback to a global mutex, I guess you can set the videodev->lock pointer and use unlocked_ioctl for those drivers that do not use a v4l2_device yet, if there are only a handful of them. Arnd -- 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
