From: Arnd Bergmann <arnd@arndb.de>
To: "Hans Verkuil" <hverkuil@xs4all.nl>
Cc: "Mauro Carvalho Chehab" <mchehab@redhat.com>,
linux-media@vger.kernel.org
Subject: Re: [RFC PATCH 0/8] V4L BKL removal: first round
Date: Tue, 16 Nov 2010 16:13:12 +0100 [thread overview]
Message-ID: <201011161613.12698.arnd@arndb.de> (raw)
In-Reply-To: <b8ec38c9574d2b83b5e9bf9fd0bb45c1.squirrel@webmail.xs4all.nl>
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.
Arnd
next prev parent reply other threads:[~2010-11-16 15:12 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-14 13:21 [RFC PATCH 0/8] V4L BKL removal: first round Hans Verkuil
2010-11-14 13:22 ` [RFC PATCH 1/8] v4l2-dev: use mutex_lock_interruptible instead of plain mutex_lock Hans Verkuil
2010-11-14 13:22 ` [RFC PATCH 2/8] BKL: trivial BKL removal from V4L2 radio drivers Hans Verkuil
2010-11-14 13:22 ` [RFC PATCH 3/8] cadet: use unlocked_ioctl Hans Verkuil
2010-11-14 13:22 ` [RFC PATCH 4/8] tea5764: convert to unlocked_ioctl Hans Verkuil
2010-11-14 13:22 ` [RFC PATCH 5/8] si4713: " Hans Verkuil
2010-11-14 13:22 ` [RFC PATCH 6/8] typhoon: " Hans Verkuil
2010-11-14 13:23 ` [RFC PATCH 7/8] dsbr100: " Hans Verkuil
2010-11-14 13:23 ` [RFC PATCH 8/8] BKL: trivial ioctl -> unlocked_ioctl video driver conversions Hans Verkuil
2010-11-14 21:53 ` [RFC PATCH 0/8] V4L BKL removal: first round Arnd Bergmann
2010-11-14 22:48 ` Hans Verkuil
2010-11-15 9:17 ` Arnd Bergmann
2010-11-15 9:49 ` Hans Verkuil
2010-11-16 12:19 ` Mauro Carvalho Chehab
2010-11-16 12:35 ` Hans Verkuil
2010-11-16 13:06 ` Mauro Carvalho Chehab
2010-11-16 13:20 ` Hans Verkuil
2010-11-16 14:22 ` Arnd Bergmann
2010-11-16 14:50 ` Hans Verkuil
2010-11-16 15:13 ` Arnd Bergmann [this message]
2010-11-16 15:27 ` Hans Verkuil
2010-11-16 15:30 ` Hans Verkuil
2010-11-16 16:01 ` Arnd Bergmann
2010-11-16 16:32 ` Mauro Carvalho Chehab
2010-11-16 16:49 ` Hans Verkuil
2010-11-16 18:38 ` Hans Verkuil
2010-11-16 19:23 ` Arnd Bergmann
2010-11-16 19:59 ` Andy Walls
2010-11-16 20:29 ` Hans Verkuil
2010-11-16 21:10 ` Hans Verkuil
2010-11-16 21:32 ` David Ellingsworth
2010-11-16 21:42 ` Hans Verkuil
2010-11-17 15:36 ` David Ellingsworth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201011161613.12698.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=hverkuil@xs4all.nl \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.