Am Donnerstag, den 07.10.2010, 17:25 +0800 schrieb Xiaofan Chen:
> On Thu, Oct 7, 2010 at 4:53 PM, Thomas Klose <thomas.klose@xxxxxxxxxxxxx>
> >> > You do not need root privileges for usb_detach_kernel_driver().
> >> >
> >> And that is one of the the beauties of using libusb and kernel
> >> driver detaching. You do not need root privileges. But you do
> >> need to set up proper udev rules.
> > Yes, libusb this is great. One thing is interesting about it: Even
> > though libusb depends on the fact that no module is attached to the USB
> > device, it does not call the detach/re-attach functions automatically.
> > The programmer who uses the library decides if it is necessary or useful
> > to do so. And that is exactly my point.
> I see your point. So if libftdi detaches the kernel driver in
> the beginning and then reattach the kernel driver in the end,
> are you happy?
> Or you really want libftdi to fail in the beginning of the
> kernel ftdi-sio driver is attached to the device. I think
> this will be a tough sell for this group.
In my opinion, the best solution would be to leave the kernel modules
untouched in the open and close functions. For convenience, functions to
detach and re-attach modules could be introduced (similar to those,
provided by libusb):
I realize, that this would break some applications. If you depend on
detaching, you would have to call the detach function first. However,
the change in the code would be minimal.
Maybe this is too drastic and the libftdi users cannot live with this
kind of changes. This is something only you can say.
An alternative would be to provide options, how to open the device. I
think this is what Uwe was suggesting in one of his earlier mails.
However, I have no idea, how you intend to do this without changing the
In any case, I think the system should be in the same condition if the
device was closed (re-attaching modules if necessary).
Regards, Thomas K.
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx