On Fri, 2005-12-09 at 11:11 -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?
>
> > 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...)
While you are discussing this stuff, you might like to consider the
problem of stealing a device from a back-end driver that has already
claimed it. I don't know if this is currently possible. With my
testing so far I have had to disable the back-end drivers for the
devices that I wanted to export to stop them from getting the devices
before me.
> 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
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
>
--
Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home