Hi,
On 01/13/2010 09:08 AM, Oliver Neukum wrote:
Am Dienstag, 12. Januar 2010 22:08:22 schrieb Hans de Goede:
Well libgphoto2 politely asks the kernel, can you please release usb device
foo for userspace use ? I'm asking for drivers to have the possibility to
say: No sorry, the device is in use.
This does not seem something strange to me. This can be hacked around
in libgphoto by:
1) Adding code to match the usb device to a /dev/video
2) If it matches a /dev/video, open that (this will work multiple opens
are allowed)
3) Try to start a stream (yes because we really want libgphoto2 to
have to start the webcam)
4) If 3) fails with ebusy, an other app is already streaming, don't ask
the kernel to release the device.
5) If 3) does not fail, close the device and continue
If you do it that way, you'll create a race. You have to kick yourself
off the device.
There will always be a race here, since the /dev/video# node won't go
away until the driver is disconnected, and an app can have that node open
already, and then try to stream later. We don't know if an app is a control
panel (think sound card mixer) application, or an app which may (eventually)
want to do streaming. In hind sight one may conclude we should have had different
device nodes for streaming and for control panel like functionality like
soundcards have, although that has its own set of problems.
I'm afraid that getting the perfect solution for this problem is hard
(basically the hardware should just have implemented 2 separate interfaces),
so I'm aiming for good enough. Assuming things like people not writing a bash
script to start a streaming app and a libgphoto2 app at exactly the same time.
That would be a gross hack, but that would be the way to "fix" libgphoto2 .
This works only if we can reliably locate all affected device nodes.
Hans, does libgphoto2 need to kick off all drivers or just the driver
for the video interface?
libgphoto2 only kicks the driver of the interface it itself wants to use, which
with these devices happens to be the same interface as which is used for
video streaming.
Or we could have the please release the device call return -EBUSY, which
almost every other single syscall in the kernel will do when a single use
device is already in use by another application.
If we do this unconditionally blocking disconnect is a bad idea. We'd
better introduce a new ioctl, like USBDEVFS_RELEASE_IDLE_INTERFACE,
to lave user space the option to kick a driver off a busy device.
Introducing a new ioctl which can be blocked by the drivers would be fine
with me. I'm in contact with the libgphoto2 devs (I mostly to the kernel
webcam driver side myself), and I'm sure I can sell that to them :)
Greg,
Would such a new ioctl be acceptable ? If not I'll start coding the
libgphoto2 solution I described before.
Regards,
Hans
--
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
