> 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.
Hans
>
> Arnd
>
--
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
