On Thu, 8 Dec 2005, Greg KH wrote:
> On Thu, Dec 08, 2005 at 11:20:35AM -0500, Alan Stern wrote:
> > Part of the problem is that the stub drivers on the back-end are forced to
> > bind to USB interfaces instead of USB devices. It would make life simpler
> > for you guys if the stub driver could bind to the entire device (replacing
> > the usb_generic driver). Do you think that's worth pursuing?
>
> My first reaction to this is NO! The usbcore has some tricks it plays
> with knowing stuff about the usb_generic driver (basically it uses it as
> a flag to prevent bad things from happening in driver core callbacks.)
Do you happen to remember if there any special tricks I need to know
about? There are all the obvious places in usb.c or device.c where the
code tests against &usb_generic_driver or &usb_generic_driver_data.
Anything else?
> But in thinking about it some more, this might be the best solution for
> all virtual bus implementations like this one, and the USB over IP
> stuff.
Yes, that was my thought too. A natural way to implement this is to make
the generic_probe routine responsible for choosing and installing a
configuration, instead of doing it as part of usb_new_device. That way,
any other (virtualizing) driver for a USB device would get just the raw
device, and it would be responsible for setting up the interfaces.
There are two difficult aspects. Since usb_generic_driver gets registered
first, it will always be probed first and so no other driver will have a
chance. Is there any simple way we can alter this? Make
usb_register_driver always move usb_generic_driver to the end of the
driver list?
(In fact, should the driver core try to define static -- or even dynamic!
-- priorities for drivers? If probing was always done in priority order,
it might help solve some other problems as well...)
The other aspect is that these drivers will have to indicate somehow (in
their id_table?) that they want to bind to devices rather than interfaces.
We might need to reserve a special code for this.
Alan Stern
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home