Re: USB driver assignment with udev

[Steve Calfee <nospamcalfee@yahoo.com>]

Hi Greg, thanks for the quick response.

Greg KH <greg <at> kroah.com> writes:
> 
> On Wed, Mar 11, 2009 at 11:20:53PM +0000, Steve Calfee wrote:
> > I am trying to understand how a USB driver gets assigned to a device.
> 
> Have you read the documentation on how this happens in the book, Linux
> Device Drivers, third edition, which is free online?

Yes, excellent book.

> > 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.
> 
> > 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.

Excellent example of what I would like to do from udev.

I understand that the kernel needs to be able to do some of this for early boot
situations where maybe userspace is not up yet. However, doing the policy
decisions of mapping drivers to devices at module build time is difficult. That
is why libusual allows module parameters to be changed at run time. However,
that is a one driver solution to a generic problem. Udev would seem to be the
proper mechanism to map drivers to devices dynamically and under control of user
space.

> 
> > 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.
> 
> What exactly are you trying to do?
> 

OK, I understand. I cannot control exactly and dynamically the mapping of
drivers to devices. The mechanism does not exist.

I am trying to figure out how to do USB/IP. The problem is some devices should
be local to the client computer and some should be virtualized to the host
computer via TCP/IP. This means removing local drivers and adding a virtual
driver (and the opposite) dynamically under user control.

There is a module parameter new_id where devices can be assigned to a module,
but no "reject_id" parameter where a reserved device can be excluded from the
probe checking. And the problem with the parameters is there is no way to remove
one once set. 

Regards, Steve