Am Dienstag, den 05.10.2010, 18:14 +0200 schrieb Uwe Bonnes: > >>>>> "Uwe" == Uwe Bonnes <[email protected]> writes: > > >>>>> "Thomas" == Thomas Klose <[email protected]> writes: > > Uwe> In your situation, however it is wrong. Ideas how to handle that > Uwe> situation are welcome. > > To clarify the situation. > Device gets plugged, ftdi_sio gets loaded. > First libftdi open calls libusb_detach_kernel_driver() and gets access. > Second libftdi open calls calls again libusb_detach_kernel_driver() and gets > access too.
To be honest, I think tampering with the system's configuration by detaching device drivers seems a little drastic to me, especially if it is default behavior. sio gets loaded because it is the driver for devices with a certain vendor and product id. If this is not wanted for a device, it should be set to another id. In comparison: If you load a driver module for a resource which is already claimed by a driver, nobody would expect it to automatically unload the other module! The user would be expected to put sio on a blacklist in /etc/modprobe.d or to unload the alternative module first. I think, the current solution compromises an important security mechanism of the kernel by preventing exclusive access to a hardware resource. Also, blindfolded detaching of modules from devices can lead to very nasty problems: Imagine device XY which does not work anymore if application Z was running on the system once... If I understand right, your solution does not address this issues. It is just an opinion, but I think the only clean solution would be to remove this function call at all. If the user wants to detach a driver, he should do it by himself, e.g. by calling the usb_detach function. For convenience maybe helper functions (ftdi_detach_sio(), ftdi_detach_sio_desc(), et cetera) could be implemented. At least there should be a way to avoid this behavior. (And again: I think it should be disabled by default.) Thanks + regards, Thomas -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
