From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from smtp-vbr1.xs4all.nl ([194.109.24.21]:3063 "EHLO smtp-vbr1.xs4all.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752929Ab0KPPas (ORCPT ); Tue, 16 Nov 2010 10:30:48 -0500 Message-ID: In-Reply-To: References: <201011161522.19758.arnd@arndb.de> <201011161613.12698.arnd@arndb.de> Date: Tue, 16 Nov 2010 16:30:29 +0100 Subject: Re: [RFC PATCH 0/8] V4L BKL removal: first round From: "Hans Verkuil" To: "Arnd Bergmann" Cc: "Mauro Carvalho Chehab" , linux-media@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT List-ID: Sender: > >> 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