libftdi Archives

Subject: Re: Claiming devices has no effect under Linux

From: Thomas Klose <thomas.klose@xxxxxxxxxxxxx>
To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Date: Tue, 05 Oct 2010 19:15:29 +0200
Am Dienstag, den 05.10.2010, 18:14 +0200 schrieb Uwe Bonnes: 
> >>>>> "Uwe" == Uwe Bonnes <bon@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
> >>>>> "Thomas" == Thomas Klose <thomas.klose@xxxxxxxxxxxxx> 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 for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx   

Current Thread