On Thu, Mar 12, 2009 at 00:37, Greg KH <greg@xxxxxxxxx> wrote:
> On Wed, Mar 11, 2009 at 11:20:53PM +0000, Steve Calfee wrote:
> Have you read the documentation on how this happens in the book, Linux
> Device Drivers, third edition, which is free online?
>
>> 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.
>
> Not really true, lots of times the module is not present.
And udev does call modprobe only for devices which are not bound to a
driver, so some of the modprobes end up doing nothing, yes, and
modprobe calls are very cheap these days, we just resolve with a
binary index a modalias string to a module name, and look if
/sys/$module exists, and exit if it's already there.
>> 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.
>
> See the libusual code for how this is handled.
>
>> 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?
>
> Not really, but I fail to see the problem that you are trying to solve
> here.
None of the solutions are provided by default, but can be made working
today, with a bit of hacking.
You can use udev rules to unbind a driver, and rebind a different one
to a specific device.
Or you can disable kernel-driver-autobinding per bus, and let udev do
all the driver binding for this bus. A default rule would trigger the
in-kernel driver binding, and any custom rule added before that, could
bind a specific driver to a specific device. What's not covered with
disabled in-kernel driver binding is the device scanning at the time
of loading of a module, which would need to be implemented.
Both setups should work. We did not see a lot of interest in offering
any solution like that. We added:
/sys/bus/*/{drivers_autoprobe,drivers_probe} long ago, because we
thought it might be useful, but it's never got really used so far, and
the missing pieces never got added to the kernel and udev.
Kay
--
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
