I am trying to understand how a USB driver gets assigned to a device. Overview: I have heard that the Apple OSX usb system does a probe and the probe routine returns a "score", which is its rating of how close a match a driver is to a device. This then lets the probing system decide which driver is the best match and after all probing starts the binding of a driver to a device. Windows seems to assume that there is usually a specific driver for each device, so it looks for a match in its registry for device allocation. It only has storage and hid as class drivers which get devices if no special driver is defined. Linux assumes the opposite from windows, that there is a generic driver for most devices. The first driver that matches a device grabs it. Question: It seems that a udev rule does a modprobe for a driver to handle a device. In most cases the module is already in-kernel and this step does nothing. The module/driver probe routine is called by the kernel, only if there is a match in its registered usb_device_id table. If more than one driver matches, the first one installed gets called first. In 2.6.16, if the probe "failed" (returned non-zero), no more modules were probed. I think this is broken, and I am now trying 2.6.28, maybe it does the right thing and continues looking for a driver that wants a device. I have a different situation, but a classic issue is if a user wants to have ub handle one device and usb-storage handle others. How can this be done? udev loads the driver, but the driver itself grabs the devices. The first module loaded will hog all the devices. USBIP will also sooner or later hit this problem, some devices might need to be local and some placed remotely. Presumably separate drivers will be needed. So right now, a Linux USB driver will in-kernel determine if it wants to bind to a particular device. This is weakly controlled by userspace by the order of module registering (usually by order of insmod). But there is no way for userspace to determine a mapping between devices and drivers. Is there a udev solution for this? Regards, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
