>
>> On Tuesday 16 November 2010, Hans Verkuil wrote:
>>> A pointer to this struct is available in vdev->v4l2_dev. However, not
>>> all
>>> drivers implement struct v4l2_device. But on the other hand, most
>>> relevant
>>> drivers do. So as a fallback we would still need a static mutex.
>>
>> Wouldn't that suffer the same problem as putting the mutex into videodev
>> as I suggested? You said that there are probably drivers that need to
>> serialize between multiple devices, so if we have a mutex per
>> v4l2_device,
>> you can still get races between multiple ioctl calls accessing the same
>> per-driver data. To solve this, we'd have to put the lock into a
>> per-driver
>> structure like v4l2_file_operations or v4l2_ioctl_ops, which would add
>> to the ugliness.
>
> 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.
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.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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
