lkml.org 
[lkml]   [2011]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: USB mini-summit at LinuxCon Vancouver
Alan Cox raised a bunch of good points.  I'm not going to respond to 
them; they pretty much speak for themselves.

On Thu, 11 Aug 2011, Mauro Carvalho Chehab wrote:

> Between two or more kernel drivers, a resource locking mechanism like the one
> you've proposed works fine,

It's not a locking mechanism. More like cooperative multi-access.

> but, when the driver is on userspace, there's one
> additional issue that needs to be addressed: What happens if, for example,
> if a camera application using libgphoto2 crashes? The lock will be enabled, and
> the V4L driver will be locked forever. Also, if the lock is made generic enough
> to protect between two different userspace applications, re-starting the
> camera application won't get the control back.

You're wrong, because what I proposed isn't a lock. If the user
program dies, the usbfs device file will automatically be closed and
then usbfs will freely give control back to the webcam driver.

If the program hangs at the wrong time, then the webcam driver won't be
able to regain control. At least the user will have the option of
killing the program when this happens; a similar hang in a kernel
driver tends to be much uglier.

Two different user programs trying to drive the device at the same time
doesn't necessarily have to cause a problem. At any particular moment,
only one of them would be in control of the device.

> To avoid such risk, kernel might need to implement some ugly hacks to detect
> when the application was killed, and put the device into a sane state, if this
> happens.

No ugly hack is needed. usbfs can directly inform the webcam driver
whether or not the device file was closed while the user program
retained control. If that didn't happen, it's safe to assume that the
program gave up control voluntarily.

> > Not all users of libgphoto2 have to be changed; only those which manage
> > dual-mode cameras. Adding a few ioctls to ask for and give up control
> > at the appropriate times must be a lot easier than porting the entire
> > driver into the kernel.
>
> Again, applications that won't implement this control will take the lock forever.

No, because there is no lock. Programs that haven't been changed will
continue to behave as they do today -- they will unbind the webcam
driver and assume full control of the device.

Alan Stern



\
 
 \ /
  Last update: 2011-08-11 17:47    [W:0.078 / U:0.888 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site