[Xen-devel] Re: [linux-usb-devel] Error recovery in Xen's paravirtualizing USB driver for Linux

[Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

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