On Wed, Jan 13, 2010 at 12:36:44AM +0100, Hans de Goede wrote: > 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. No, I don't think it is acceptable, you should solve this in libgphoto itself. Remember, even if you did introduce such an ioctl, you still have the sysfs unbind/bind files to contend with, which nothing in the USB core could handle, so your solution would be incomplete, and complicated to understand. thanks, greg k-h -- 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
