On Tue, Jan 12, 2010 at 10:08:22PM +0100, Hans de Goede wrote: > Hi, > > On 01/12/2010 09:01 PM, Greg KH wrote: > >>> Fixing userspace bugs with kernel driver changes seems a bit harsh :) > >> > >> Oh I completely agree, and I also agree that apps which looses their > >> /dev/video device because of unplug should handle that properly, still > >> the stealing of the device from the webcam app by libgphoto apps is > >> unwanted behavior in my book, and that is what I'm trying to fix. > > > > Then fix libgphoto please. I don't see a kernel issue here yet. > > > > 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. But why not just fix libgphoto2? > 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 > > That would be a gross hack, but that would be the way to "fix" libgphoto2 . That sounds like the real solution, and not a "hack" as that is what you want libgphoto2 to do. Only if another application has the video device open do you not want to grab it. And it sounds like it will work just fine with no kernel changes, which means it is backwards compatible to all older kernel versions, making existing users happy. > 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. This is not the same thing as a syscall, it's a device/driver binding. Are you also going to somehow want to override the sysfs "disconnect this device from its driver" functionality as well? Because that is what I have seen some userspace programs do already, and not mess around with the usbfs ioctl call, as its much easier to do from scripting languages. 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
