On Fri, Dec 09, 2005 at 11:11:12AM -0500, Alan Stern wrote:
> 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?
Not that I can think of right away, no.
> > 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?
Ick, that would be ugly. But I think we manually bind that driver to
the device before we register it and don't let the core do the binding.
So we could have some logic there of our own.
> (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...)
We've wanted this for a long time. But the priorities would have to be
on the bus level, as they are the portion of code that knows how to
match things up.
> 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.
Just a different function to register this type of driver with the
usb-serial core. It's not that complex.
Hope this helps,
greg k-h
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home