> I don't quite understand about the races - but that's because I don't > understand the underlying mechanics. Can you elaborate or point me to some > material that better explains what's going on?
Actually I discourage using locks like BKL. The basic issue is that there are several code paths that compete with each other for driver resources. They need mutual exclusion, so spinlocks and/or binary semaphores (mutexes) are appropriate. One lock is needed to protect individual devices: - app threads using File.open(), read(), ioctl(), etc on a given device - khubd invoking usb_device.disconnect() to report device removal Another lock must protect the set of devices: - app threads accessing the set in File.open() - khubd modifying it in usb_device.probe() or disconnect() Rule of thumb is as always to hold the lock if some other execution context may be trying to access the same data at the same time, and to use the lightest weight lock you can (so avoid BKL:). And release the lock even on exit paths due to errors. I've not looked specifically at that scanner patch, but that general background applies to most USB devices that go through the filesystem. (Network drivers have different entry points.) - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
