> Between two or more kernel drivers, a resource locking mechanism like the one > you've proposed works fine, 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. Actually there are more issues than that - you've also got to worry about a security/permission model, and that is hard to get right, especially if you are not very careful that anything that can be retrieved which might violate the security model (eg the last frame on the capture) has been blanked before handover etc. > 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. At which point history says it's easier to do the job right, once, in the kernel. > Again, applications that won't implement this control will take the lock forever. And applications that are touching both video (even indirectly) and still camera may get surprise deadlocks if they accidentally reference both the still and video device even via some library or service. > > Well, a user program can assume that the kernel driver left the device > > in a clean state. The reverse isn't always true, however -- it's one Not it cannot - the user program doesn't know a) if the kernel driver has ever been loaded b) the values the kernel driver leaves set (and those will change no doubt at times) c) if the camera has been plugged and unplugged and not yet had the kernel driver loaded To me it sounds like a recipe for disaster. For those tiny number of devices involved just use V4L and if need be some small V4L tweaks to handle still mode. In most cases the interface is basically identical and I'd bet much of the code is identical too. Alan -- 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