Re: USB mini-summit at LinuxCon Vancouver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux