On Wed, Oct 6, 2010 at 4:39 PM, Thomas Klose <thomas.klose@xxxxxxxxxxxxx> wrote:
> Am Mittwoch, den 06.10.2010, 16:31 +0800 schrieb Xiaofan Chen:
>> Sorry but this is the way how libusb works. I do not under why you say
>> this is not the Linux way to do things. If you use libusb, you have
>> to detach the kernel driver.
>>
>
> If the device has a VID/PID which is associated with a kernel module I
> would expect that module to be loaded. If a device is not intended to be
> used with sio it *must* use another VID/PID. This is the whole idea
> behind the VID/PID system.
This is actually not true. Just a simple example, if you do not have
Windows, and want to change the EEPROM configuration of the
FTDI device. Then you can use Uwe's application which is based
on libftdi. So you will need to detach the exisiting kernel driver to do
it. So give the user the freedom to either use the kernel driver or
use libftdi is very good.
There are often cases that the kernel driver may not be the best
to be used.
The Linux capability of being able to attach/detach a kernel
driver is really a blessing, if you ask the libusb users.
> If for some reason the user explicitly does not want the system to load
> a certain module, he can create an blacklist entry in /etc/modprobe.d
This is one way, but not the only way. Last time it might be the only
way, now it is not.
Another example is libhid for HID device. You can detach the
kernel HID driver to use libhid. There are many generic HID device
out there yet the kernel HID driver is not so good. So one way is
to blacklist the device, the other way is to detach the kernel HID
driver.
> This is the Linux way to do those things.
Your way is one way to do things. Again, the ability to detach the kernel
driver by program is a blessing for Linux if you ask the libusb users.
Unfortunately it is not as easy under Windows and Mac OS X.
--
Xiaofan
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
