Xen devel - Dec 2005 - Error recovery in Xen''s paravirtualizing USB driver for Linux

USB Folks,

    I''ve been working on a USB device driver for Linux running
paravirtualized on the Xen hypervisor and I have a few questions about
the design of the error recovery...

    This ''USB split driver'' has a
''front-end'' in the Linux kernel
running in a guest domain of the hypervisor and a ''back-end''
in the
Linux kernel running in a device driver domain (usually the special
privilidged domain 0).

    The user configures Xen to map a USB port from the back-end domain
to the front-end domain and the split driver makes any USB device
attached to the back-end port available in the front-end domain.

    The split driver works roughly as follows:

o - The back-end uses usb_register to register itself as a driver
matching all USB IDs so it gets probed for every USB device that is
connected.  When a USB device is probed for a configured port, the
driver claims all the interfaces for the device.

o - The front-end uses usb_create_hcd to create a HCD with a single
port.

o - The front-end and the back-end communicate using the Xen
inter-domain communication primitives so the hub status in the front-end
reflects whether or not a device is plugged into the back-end port.

o - URBs received by the front-end HCD are translated into Xen
inter-domain-communication primitives and routed to the back-end domain.

o - The inter-domain communication primitives are translated back into
URBs in the back-end and submitted to the Linux USB stack for the device
attached to the back-end port.

    The split driver now works well enough to mount a filesystem on a
USB key in the front-end domain so it''s getting there.

    I did have a problem with URBs getting reordered on their way
between the front-end and the back-end which led to miscompares where
the correct bulk data was written on the USB key but at the wrong LBA. I
fixed this by maintaining submission ordering in the URB queue from
front-end to back-end.

    This issue made me realize there was a similar problem during error
recovery if an URB fails when there are several in flight and indeed,
reading the recent USB code, there is a big comment about the guarantees
a driver gets on an error: the URB queue stalls until the driver''s
completion handler returns from completion of the failing URB and any
URBs unlinked during completion of the failing URB.

    Right now, if there is an error on an URB in my USB split driver
back-end then the back-end completion handler returns before the front
end USB driver client''s completion handler gets a chance to do any
unlinks so the URBs are not stalled and my driver is broken.  I''m
trying
to work out how to fix it.

    I''m thinking of doing the following:

    When there is an error returned by an URB in the back-end, the
completion handler of the back end will unlink all of the URBs in
progress for the endpoint of the failing URB and set a
''fail_urb'' flag
for the endpoint to fail back any URBs which arrive subsequently for
that endpoint until the ''fail_urb'' flag is reset.

    Whenever the front-end completion handler returns from completing an
URB back to the client and finds that an endpoint has gone idle it will
set a flag to indicate that the next URB sent to the back-end for that
endpoint should clear the ''fail_urb'' flag in the back end
before
starting.

    This strategy is similar to the concept of auto contingent
allegiance for SCSI.

    My questions are as follows:

1) I think it is impossible to maintain exactly the same guarantee that
the Linux USB stack provides across the Xen inter-domain interface
because I don''t think it is desirable to attempt the synchronisation of
the two kernels in different domains required to nest the call of the
front end completion within the call of the back end completion.  Is
this correct?

2) I believe the above strategy to be more conservative than the Linux
guarantee and sufficient to avoid miscompares due to re-ordering as a
result of URBs failing whilst there are multiple URBs in flight.  Is
this correct?

3) I think the above strategy is compatible with the suggested recovery
mechanism for Linux USB drivers which is to unlink outstanding URBs in
the URB completion handler.  Is the above strategy likely to work?

4) I''m wondering what error to fail URBs with when
''fail_urb'' is set.
I''m guessing either -ECONNRESET which is the same as if the URB was
unlinked or perhaps -EAGAIN.  What would be the correct value?

5) Is there a more USBish way to solve this problem that will fit better
with the USB infrastructure.

6) Any other ideas?

Thanks for your help!

Harry Butterworth


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 7 Dec 2005, harry wrote:
> USB Folks,
> 
>     I''ve been working on a USB device driver for Linux running
> paravirtualized on the Xen hypervisor and I have a few questions about
> the design of the error recovery...
> 
>     This ''USB split driver'' has a
''front-end'' in the Linux kernel
> running in a guest domain of the hypervisor and a
''back-end'' in the
> Linux kernel running in a device driver domain (usually the special
> privilidged domain 0).
> 
>     The user configures Xen to map a USB port from the back-end domain
> to the front-end domain and the split driver makes any USB device
> attached to the back-end port available in the front-end domain.
> 
>     The split driver works roughly as follows:
> 
> o - The back-end uses usb_register to register itself as a driver
> matching all USB IDs so it gets probed for every USB device that is
> connected.  When a USB device is probed for a configured port, the
> driver claims all the interfaces for the device.
> 
> o - The front-end uses usb_create_hcd to create a HCD with a single
> port.
> 
> o - The front-end and the back-end communicate using the Xen
> inter-domain communication primitives so the hub status in the front-end
> reflects whether or not a device is plugged into the back-end port.
> 
> o - URBs received by the front-end HCD are translated into Xen
> inter-domain-communication primitives and routed to the back-end domain.
> 
> o - The inter-domain communication primitives are translated back into
> URBs in the back-end and submitted to the Linux USB stack for the device
> attached to the back-end port.
> 
>     The split driver now works well enough to mount a filesystem on a
> USB key in the front-end domain so it''s getting there.
> 
>     I did have a problem with URBs getting reordered on their way
> between the front-end and the back-end which led to miscompares where
> the correct bulk data was written on the USB key but at the wrong LBA. I
> fixed this by maintaining submission ordering in the URB queue from
> front-end to back-end.
Clearly this is necessary for any queue, not just queues of USB URBs.
>     This issue made me realize there was a similar problem during error
> recovery if an URB fails when there are several in flight and indeed,
> reading the recent USB code, there is a big comment about the guarantees
> a driver gets on an error: the URB queue stalls until the driver''s
> completion handler returns from completion of the failing URB and any
> URBs unlinked during completion of the failing URB.
> 
>     Right now, if there is an error on an URB in my USB split driver
> back-end then the back-end completion handler returns before the front
> end USB driver client''s completion handler gets a chance to do any
> unlinks so the URBs are not stalled and my driver is broken.  I''m
trying
> to work out how to fix it.
> 
>     I''m thinking of doing the following:
> 
>     When there is an error returned by an URB in the back-end, the
> completion handler of the back end will unlink all of the URBs in
> progress for the endpoint of the failing URB and set a
''fail_urb'' flag
> for the endpoint to fail back any URBs which arrive subsequently for
> that endpoint until the ''fail_urb'' flag is reset.
> 
>     Whenever the front-end completion handler returns from completing an
> URB back to the client and finds that an endpoint has gone idle it will
> set a flag to indicate that the next URB sent to the back-end for that
> endpoint should clear the ''fail_urb'' flag in the back end
before
> starting.
Failing isn''t the right approach.  The back-end should unlink all those
URBs but keep them available, so that they can be resubmitted if 
necessary.  When the front-end learns about the error, it has the option 
of unlinking the URBs or not -- if it doesn''t unlink them then the 
back-end should resubmit them.  Likewise for URBs received from the front 
end before the flag is cleared; they should be kept on the queue so that 
they can be submitted when the front-end''s completion routine returns.
>     This strategy is similar to the concept of auto contingent
> allegiance for SCSI.
> 
>     My questions are as follows:
> 
> 1) I think it is impossible to maintain exactly the same guarantee that
> the Linux USB stack provides across the Xen inter-domain interface
> because I don''t think it is desirable to attempt the
synchronisation of
> the two kernels in different domains required to nest the call of the
> front end completion within the call of the back end completion.  Is
> this correct?
That is not a USB question; it has more to do with the organization of 
Xen.  I don''t know enough about Xen to answer fully.  But if this 
inter-kernel synchronization requires any kind of sleeping, then you
can''t
use it in the context of a USB completion routine.
> 2) I believe the above strategy to be more conservative than the Linux
> guarantee and sufficient to avoid miscompares due to re-ordering as a
> result of URBs failing whilst there are multiple URBs in flight.  Is
> this correct?
Forget about miscompares; you should be concerned about re-ordering of 
URBs in any context.  The strategy you outlined, with the changes 
suggested above, should suffice to fulfill the Linux USB stack''s
guarantee
for a virtual kernel.
> 3) I think the above strategy is compatible with the suggested recovery
> mechanism for Linux USB drivers which is to unlink outstanding URBs in
> the URB completion handler.  Is the above strategy likely to work?
Usually you do want to unlink all the URBs in a queue when one of them 
fails.  But there are times when you don''t.  A good example is URBs 
submitted to endpoint 0.  They can arrive independently from separate 
origins (a driver, the USB core, or userspace via usbfs) and failure of 
one shouldn''t affect the others.
> 4) I''m wondering what error to fail URBs with when
''fail_urb'' is set.
> I''m guessing either -ECONNRESET which is the same as if the URB
was
> unlinked or perhaps -EAGAIN.  What would be the correct value?
Do what I said: don''t fail the URBs.  Just keep them handy until the 
front-end cancels them itself or clears the flag.  Then there''s no need
for an error code.
> 5) Is there a more USBish way to solve this problem that will fit better
> with the USB infrastructure.
> 
> 6) Any other ideas?
Suspend/resume is liable to cause trouble.  For instance, what happens to 
the various front-ends if the back-end decides to suspend a USB device?

Alan Stern


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 2005-12-07 at 14:35 -0500, Alan Stern wrote:
> >     I did have a problem with URBs getting reordered on their way
> > between the front-end and the back-end which led to miscompares where
> > the correct bulk data was written on the USB key but at the wrong LBA.
I
> > fixed this by maintaining submission ordering in the URB queue from
> > front-end to back-end.
> 
> Clearly this is necessary for any queue, not just queues of USB URBs.
Some queues, for example sets of SCSI queue simple commands, are allowed
to be reordered.  This is useful for rotational position optimisation on
single disk drives and concurrency on RAID arrays.  Ordering makes sense
for USB though---it just didn''t click with me immediately.
> Failing isn''t the right approach.  The back-end should unlink all
those
> URBs but keep them available, so that they can be resubmitted if 
> necessary.  When the front-end learns about the error, it has the option 
> of unlinking the URBs or not -- if it doesn''t unlink them then the
> back-end should resubmit them.  Likewise for URBs received from the front 
> end before the flag is cleared; they should be kept on the queue so that 
> they can be submitted when the front-end''s completion routine
returns.
Thanks.  This is exactly the information I was looking for.
> Suspend/resume is liable to cause trouble.  For instance, what happens to 
> the various front-ends if the back-end decides to suspend a USB device?
I don''t know.  Could you explain this scenario in more detail (imagine
that none of the 800 page USB spec sunk in when I read it :-).  What
should happen in this case?

-- 
Harry Butterworth <harry@hebutterworth.freeserve.co.uk>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 07 Dec 2005 18:31:17 +0000, harry
<harry@hebutterworth.freeserve.co.uk> wrote:
>     This ''USB split driver'' has a
''front-end'' in the Linux kernel
> running in a guest domain of the hypervisor and a
''back-end'' in the
> Linux kernel running in a device driver domain (usually the special
> privilidged domain 0).
Why don''t you just let guest 0 to own the controller? This is what
the guest 0 is for, as far as I know.

If you create special stub drivers in the hypervisor, you might as
well create virtual USB controllers for nonzero guests.
> o - The back-end uses usb_register to register itself as a driver
> matching all USB IDs so it gets probed for every USB device that is
> connected.  When a USB device is probed for a configured port, the
> driver claims all the interfaces for the device.
Ewww! Ewww!

You are just going to hit all the difficulties the vmware guy hit,
perhaps minus the size limitation in usbfs since you are bypassing it.

I would expect that the scheme you''re proposing were employed to
let non-zero guests to drive some virtualized devices, but not for
the guest zero.

-- Pete

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 2005-12-07 at 15:00 -0800, Pete Zaitcev wrote:
> On Wed, 07 Dec 2005 18:31:17 +0000, harry
<harry@hebutterworth.freeserve.co.uk> wrote:
> 
> >     This ''USB split driver'' has a
''front-end'' in the Linux kernel
> > running in a guest domain of the hypervisor and a
''back-end'' in the
> > Linux kernel running in a device driver domain (usually the special
> > privilidged domain 0).
> 
> Why don''t you just let guest 0 to own the controller? This is what
> the guest 0 is for, as far as I know.
Guest 0 normally owns the controller.  Xen also has a concept of driver
domains where you give a PCI device to a privileged guest other than 0
and run the driver in that guest.  This is useful for driver development
amongst other things.

> 
> If you create special stub drivers in the hypervisor, you might as
> well create virtual USB controllers for nonzero guests.
The stub drivers are not in the hypervisor but are for the Linux kernels
run in the hypervisor virtual machines (domains).
Yes, the front-end driver in the non-zero guest creates a virtual USB
controller.
> 
> > o - The back-end uses usb_register to register itself as a driver
> > matching all USB IDs so it gets probed for every USB device that is
> > connected.  When a USB device is probed for a configured port, the
> > driver claims all the interfaces for the device.
> 
> Ewww! Ewww!
What should I be doing?
> 
> You are just going to hit all the difficulties the vmware guy hit,
What were they?
> perhaps minus the size limitation in usbfs since you are bypassing it.
> 
> I would expect that the scheme you''re proposing were employed to
> let non-zero guests to drive some virtualized devices, but not for
> the guest zero.
Yes, it''s for letting non-zero guest domains run USB drivers for
devices
attached to ports on USB controllers which are driven by domain 0.

So, for example you can have one physical USB port, plug in a four port
USB HUB and then map one port on the HUB to each of four guest domains.
Any device plugged into the port mapped to a given guest domain will
appear attached to a port on the virtual USB controller in the guest
domain.

USB devices in domain zero are just driven by the normal USB driver
code.  My split driver is not involved.  Sorry for not being clear.

Harry.

-- 
Harry Butterworth <harry@hebutterworth.freeserve.co.uk>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 7 Dec 2005, Harry Butterworth wrote:
> > Suspend/resume is liable to cause trouble.  For instance, what happens
to
> > the various front-ends if the back-end decides to suspend a USB
device?
> 
> I don''t know.  Could you explain this scenario in more detail
(imagine
> that none of the 800 page USB spec sunk in when I read it :-).  What
> should happen in this case?
Suspend and reset are both troublemakers, because they act not on a device 
but on the device''s parent hub.  However resets are pretty
self-contained,
so provided you recognize them and handle them properly you should be 
okay.  The back-end won''t reset a device all by itself.

The problems with USB suspend are just a small subset of the problems with 
suspend in general.  What happens to a front-end if a back-end goes to 
sleep, for example?

Your best approach is to make sure that a back-end never tries to suspend
an exported device.  Then the front-end will be completely responsible for 
device power management, and no confusion will arise.

Alan Stern


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2005-12-08 at 10:20 -0500, Alan Stern wrote:
> On Wed, 7 Dec 2005, Harry Butterworth wrote:
> 
> > > Suspend/resume is liable to cause trouble.  For instance, what
happens to
> > > the various front-ends if the back-end decides to suspend a USB
device?
> > 
> > I don''t know.  Could you explain this scenario in more detail
(imagine
> > that none of the 800 page USB spec sunk in when I read it :-).  What
> > should happen in this case?
> 
> Suspend and reset are both troublemakers, because they act not on a device 
> but on the device''s parent hub.  However resets are pretty
self-contained,
> so provided you recognize them and handle them properly you should be 
> okay.  The back-end won''t reset a device all by itself.
> 
> The problems with USB suspend are just a small subset of the problems with 
> suspend in general.  What happens to a front-end if a back-end goes to 
> sleep, for example?
In the current implementation, the virtual hub in the front-end ignores
or fakes up anything to do with power management and doesn''t pass it to
the back-end.

I was assuming that the back-end would do it''s own power management and
that if it put anything to sleep it would wake it up again for me when
my driver submitted an URB.  This is probably totally naive.

Are the individual USB drivers actually involved in power management or
is it managed by the hub driver transparently to the usb drivers?  If
it''s managed transparently then I ought to be able to leave it all to
the back-end, right?
> 
> Your best approach is to make sure that a back-end never tries to suspend
> an exported device.  Then the front-end will be completely responsible for 
> device power management, and no confusion will arise.
I''m not actually giving the front-end access to the back-end hub, only
to a device plugged into the hub.  The front-end gets its own virtual
hub.  So, if I have to have the front-end do the power management then
I''ll have to handle the power management requests to the front-end
virtual hub and forward them to the backend and translate them into
requests to the back-end hub.

I''d prefer to let the back-end do it if at all possible.

Thoughts?
> 
> 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@lists.sourceforge.net
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 8 Dec 2005, Harry Butterworth wrote:
> In the current implementation, the virtual hub in the front-end ignores
> or fakes up anything to do with power management and doesn''t pass
it to
> the back-end.
> 
> I was assuming that the back-end would do it''s own power
management and
> that if it put anything to sleep it would wake it up again for me when
> my driver submitted an URB.  This is probably totally naive.
It is.  For one thing, drivers aren''t allowed to submit URBs to
suspended
devices.
> Are the individual USB drivers actually involved in power management or
> is it managed by the hub driver transparently to the usb drivers?
Both.  :-)

Drivers are involved in power management of their interfaces (remember, 
drivers bind to USB interfaces, not to USB devices).  The hub driver is 
involved in power management of USB devices (and hub interfaces too, of 
course).
>  If
> it''s managed transparently then I ought to be able to leave it all
to
> the back-end, right?
I''m not sure what you mean by that.  Do you _want_ to virtualize power 
management operations?  If not, have your virtual root hub pretend to 
carry them out without actually doing anything.  If yes, your virtual root 
hub will have to forward suspend and resume requests to the actual parent 
hub on the back-end.

A complication is that suspended USB devices may send remote wakeup 
requests.  If you only pretend to suspend the device then those wakeup 
requests will never get sent.  Maybe you don''t care about such esoteric
details...
> I''m not actually giving the front-end access to the back-end hub,
only
> to a device plugged into the hub.  The front-end gets its own virtual
> hub.  So, if I have to have the front-end do the power management then
> I''ll have to handle the power management requests to the front-end
> virtual hub and forward them to the backend and translate them into
> requests to the back-end hub.
That''s right.

You have to do this sort of thing anyway.  How else can you handle port
resets?  They occur as a normal part of the device initialization sequence 
and as part of error recovery in usb-storage, among other things.
> I''d prefer to let the back-end do it if at all possible.
Prefer to let the back-end do what?

You know, there are other awkward aspects to watch out for.  For example, 
the USB-over-IP patch included special code to check for Clear-Halt 
requests and Set-Interface requests.  It also needed (but forgot to 
include) code to check for Set-Configuration requests.

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?

Alan Stern


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2005-12-08 at 11:20 -0500, Alan Stern wrote:
> On Thu, 8 Dec 2005, Harry Butterworth wrote:
> 
> > In the current implementation, the virtual hub in the front-end
ignores
> > or fakes up anything to do with power management and doesn''t
pass it to
> > the back-end.
> > 
> > I was assuming that the back-end would do it''s own power
management and
> > that if it put anything to sleep it would wake it up again for me when
> > my driver submitted an URB.  This is probably totally naive.
> 
> It is.  For one thing, drivers aren''t allowed to submit URBs to
suspended
> devices.
> 
> > Are the individual USB drivers actually involved in power management
or
> > is it managed by the hub driver transparently to the usb drivers?
> 
> Both.  :-)
> 
> Drivers are involved in power management of their interfaces (remember, 
> drivers bind to USB interfaces, not to USB devices).  The hub driver is 
> involved in power management of USB devices (and hub interfaces too, of 
> course).
> 
> >  If
> > it''s managed transparently then I ought to be able to leave
it all to
> > the back-end, right?
> 
> I''m not sure what you mean by that.  Do you _want_ to virtualize
power
> management operations?
I want to do the minimum amount of work to get the system working
reliably.  Virtualization of power management isn''t a high priority.
> If not, have your virtual root hub pretend to 
> carry them out without actually doing anything.
Right.  That''s what it does at the moment.
> If yes, your virtual root 
> hub will have to forward suspend and resume requests to the actual parent 
> hub on the back-end.
> 
> A complication is that suspended USB devices may send remote wakeup 
> requests.  If you only pretend to suspend the device then those wakeup 
> requests will never get sent.  Maybe you don''t care about such
esoteric
> details...
Are the remote wakeup requests actually needed for anything if the
device isn''t really suspended?
> 
> > I''m not actually giving the front-end access to the back-end
hub, only
> > to a device plugged into the hub.  The front-end gets its own virtual
> > hub.  So, if I have to have the front-end do the power management then
> > I''ll have to handle the power management requests to the
front-end
> > virtual hub and forward them to the backend and translate them into
> > requests to the back-end hub.
> 
> That''s right.
> 
> You have to do this sort of thing anyway.  How else can you handle port
> resets?  They occur as a normal part of the device initialization sequence 
> and as part of error recovery in usb-storage, among other things.
Yes, port resets are currently handled like this in the front-end and
forwarded to the back-end.  They aren''t actually actioned in the
back-end at the moment (except to reset the simulated device address)
but I can put in a call to reset the real device if it is necessary.
> > I''d prefer to let the back-end do it if at all possible.
> 
> Prefer to let the back-end do what?
Any power management.
> 
> You know, there are other awkward aspects to watch out for.  For example, 
> the USB-over-IP patch included special code to check for Clear-Halt 
> requests and Set-Interface requests.  It also needed (but forgot to 
> include) code to check for Set-Configuration requests.
OK, I''ll have a look at the USB-over-IP patch for those requests.

Any idea what I should do for set-configuration? Currently I have the
following code: /* FIXME: what to do for set configuration? */ :-)
> 
> 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?
I''ll look into it.  If it means that there is a cleaner split in
responsibility between the front-end and the back-end then it might
help.  One issue is the problem of letting the front-end have any
control over device configurations because it won''t know about the
other
devices connected to the back-end hub and so can''t choose
configurations
or manage the hub power accordingly.

				*****

I''m still a bit confused by power management.  You say that the hub
does
device power management and the drivers do interface power management...

Currently my back-end code is just a client of the normal linux USB
stack so, presumably the linux hub driver in the back-end will keep
doing whatever device power management it was doing before for the
devices that I''m exporting.  I''m not making any explicit power
management calls for the devices in the back-end.

Any device power management in the front-end is also presumably done by
the linux hub driver in the front-end and my front-end virtual hub just
fakes it out or ignores it.

So, is this an OK solution for device power management?

As far as interface power management goes, all I can find in the spec is
a reference to another document describing the INTERFACE_POWER
descriptor which a bit of googling seems to indicate was withdrawn from
the standard shortly after being released.

What exactly do you mean by interface power management?

I''m assuming that anything the driver is doing to its interface is done
by submitting an URB in the front-end which will be forwarded to the
back-end and submitted to the back-end device interface.  Since the
back-end driver is not submitting any of its own URBs there should be no
interference between back and front-end drivers for any interface power
management.

Is this correct?

So, I think the power management strategy for my current code might be
reasonable.

Can you still see anything wrong with it?
> 
> 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@lists.sourceforge.net
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 8 Dec 2005, Harry Butterworth wrote:
> > I''m not sure what you mean by that.  Do you _want_ to
virtualize power
> > management operations?
> 
> I want to do the minimum amount of work to get the system working
> reliably.  Virtualization of power management isn''t a high
priority.
Then for the moment you can keep your current strategy.  Eventually it 
will make a difference, though.  The front-end will want to power-manage 
its devices and you''ll have to cope with it.
> > A complication is that suspended USB devices may send remote wakeup 
> > requests.  If you only pretend to suspend the device then those wakeup
> > requests will never get sent.  Maybe you don''t care about
such esoteric
> > details...
> 
> Are the remote wakeup requests actually needed for anything if the
> device isn''t really suspended?
Well yes -- they''re needed for telling the front-end that the virtual
device wants to be resumed.  (Actually, according to the USB spec, remote
wakeup messages mean that the device already _has_ been resumed.  It''s
a
little peculiar...)

For example, suppose the front-end is so tremendously power-conscious that 
it suspends USB keyboards between keystrokes.  The remote wakeup mechanism 
then will be critical for letting the front-end know that a new keystroke 
has arrived and the host needs to process it.

> > You have to do this sort of thing anyway.  How else can you handle
port
> > resets?  They occur as a normal part of the device initialization
sequence
> > and as part of error recovery in usb-storage, among other things.
> 
> Yes, port resets are currently handled like this in the front-end and
> forwarded to the back-end.  They aren''t actually actioned in the
> back-end at the moment (except to reset the simulated device address)
> but I can put in a call to reset the real device if it is necessary.
You will find that it _is_ necessary for error recovery in usb-storage.  
You''ll have to call usb_reset_device.
> > > I''d prefer to let the back-end do it if at all possible.
> > 
> > Prefer to let the back-end do what?
> 
> Any power management.
But that means preventing the front-end from trying to do power 
management.  How do you do that?  Only allow front-end kernels that have 
been built with CONFIG_PM not set?

> Any idea what I should do for set-configuration? Currently I have the
> following code: /* FIXME: what to do for set configuration? */ :-)
That''s a bit of a problem when the front-end is trying to install
config
0.  Actually doing it in the back-end would unbind your stub driver,
making the front-end think the device had been unplugged.  The same would
be true whenever the new config was different from the old one.  This is 
one of those places where binding your stub driver to the device instead 
of to the interfaces would help.

> > 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?
> 
> I''ll look into it.  If it means that there is a cleaner split in
> responsibility between the front-end and the back-end then it might
> help.  One issue is the problem of letting the front-end have any
> control over device configurations because it won''t know about the
other
> devices connected to the back-end hub and so can''t choose
configurations
> or manage the hub power accordingly.
I''ve got a patch-in-progress that will help the hub-power issue.

Letting a driver bind to devices would make things somewhat cleaner. 
It''s
not implemented currently in the kernel; it''s one of the things
I''ve been
considering adding.

> I''m still a bit confused by power management.  You say that the
hub does
> device power management and the drivers do interface power management...
> 
> Currently my back-end code is just a client of the normal linux USB
> stack so, presumably the linux hub driver in the back-end will keep
> doing whatever device power management it was doing before for the
> devices that I''m exporting.  I''m not making any explicit
power
> management calls for the devices in the back-end.
> 
> Any device power management in the front-end is also presumably done by
> the linux hub driver in the front-end and my front-end virtual hub just
> fakes it out or ignores it.
> 
> So, is this an OK solution for device power management?
I think it''s okay, except for that sticky point concerning remote
wakeup.
As long as the front-end doesn''t try to do aggressive power management 
(which Linux has not yet implemented) you should be fine.
> As far as interface power management goes, all I can find in the spec is
> a reference to another document describing the INTERFACE_POWER
> descriptor which a bit of googling seems to indicate was withdrawn from
> the standard shortly after being released.
> 
> What exactly do you mean by interface power management?
It''s not really a formal USB term.  I mean notifying drivers (which
manage
interfaces) about power management events.  Basically, a driver needs to 
cancel all its URBs when the device is about to be suspended and resubmit 
them when the device resumes.  In between, of course, it should not try to 
submit any URBs.
> I''m assuming that anything the driver is doing to its interface is
done
> by submitting an URB in the front-end which will be forwarded to the
> back-end and submitted to the back-end device interface.  Since the
> back-end driver is not submitting any of its own URBs there should be no
> interference between back and front-end drivers for any interface power
> management.
> 
> Is this correct?
There should be no interference provided the back-end doesn''t try to
suspend any devices all by itself.  To protect against that possibility,
your stub driver should be written so that its suspend method sends the
front-end a virtual disconnect event and its resume method sends a virtual
connect event.  That''s probably about the same as what the probe and
disconnect methods do now.

(I expect you''re careful about sending these connect and disconnect 
events for devices with multiple interfaces.  Like, send them only the 
_first_ time an interface is probed/resumed and the _last_ time an 
interface is disconnected/suspended.)
> So, I think the power management strategy for my current code might be
> reasonable.
> 
> Can you still see anything wrong with it?
So long as you can ignore the remote wakeup problem, you should be good.

Alan Stern


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2005-12-08 at 13:53 -0500, Alan Stern wrote:
> On Thu, 8 Dec 2005, Harry Butterworth wrote:
> 
> > > I''m not sure what you mean by that.  Do you _want_ to
virtualize power
> > > management operations?
> > 
> > I want to do the minimum amount of work to get the system working
> > reliably.  Virtualization of power management isn''t a high
priority.
> 
> Then for the moment you can keep your current strategy.  Eventually it 
> will make a difference, though.  The front-end will want to power-manage 
> its devices and you''ll have to cope with it.
OK.
> 
> > > A complication is that suspended USB devices may send remote
wakeup
> > > requests.  If you only pretend to suspend the device then those
wakeup
> > > requests will never get sent.  Maybe you don''t care
about such esoteric
> > > details...
> > 
> > Are the remote wakeup requests actually needed for anything if the
> > device isn''t really suspended?
> 
> Well yes -- they''re needed for telling the front-end that the
virtual
> device wants to be resumed.  (Actually, according to the USB spec, remote
> wakeup messages mean that the device already _has_ been resumed. 
It''s a
> little peculiar...)
> 
> For example, suppose the front-end is so tremendously power-conscious that 
> it suspends USB keyboards between keystrokes.  The remote wakeup mechanism 
> then will be critical for letting the front-end know that a new keystroke 
> has arrived and the host needs to process it.
OK.  I think I understand this point now.
> 
> 
> > > You have to do this sort of thing anyway.  How else can you
handle port
> > > resets?  They occur as a normal part of the device initialization
sequence
> > > and as part of error recovery in usb-storage, among other things.
> > 
> > Yes, port resets are currently handled like this in the front-end and
> > forwarded to the back-end.  They aren''t actually actioned in
the
> > back-end at the moment (except to reset the simulated device address)
> > but I can put in a call to reset the real device if it is necessary.
> 
> You will find that it _is_ necessary for error recovery in usb-storage.  
> You''ll have to call usb_reset_device.
OK.
> 
> > > > I''d prefer to let the back-end do it if at all
possible.
> > > 
> > > Prefer to let the back-end do what?
> > 
> > Any power management.
> 
> But that means preventing the front-end from trying to do power 
> management.  How do you do that?  Only allow front-end kernels that have 
> been built with CONFIG_PM not set?
I meant the real power management.  I was assuming the front-end would
fake-up power management.  But you have changed my mind.  Now I think
the right thing to do is let the front-end do the power management of
the devices exported to it subject to the isolation requirements of
sharing the hub with other front-ends.  Implementing this can wait
though.  For the time being I''ll keep the current strategy.
> 
> > Any idea what I should do for set-configuration? Currently I have the
> > following code: /* FIXME: what to do for set configuration? */ :-)
> 
> That''s a bit of a problem when the front-end is trying to install
config
> 0.  Actually doing it in the back-end would unbind your stub driver,
> making the front-end think the device had been unplugged.  The same would
> be true whenever the new config was different from the old one.  This is 
> one of those places where binding your stub driver to the device instead 
> of to the interfaces would help.
Yes.  At the moment my code does nothing which I think means it''s only
going to work for devices which don''t have to change the configuration.
> 
> 
> > > 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?
> > 
> > I''ll look into it.  If it means that there is a cleaner split
in
> > responsibility between the front-end and the back-end then it might
> > help.  One issue is the problem of letting the front-end have any
> > control over device configurations because it won''t know
about the other
> > devices connected to the back-end hub and so can''t choose
configurations
> > or manage the hub power accordingly.
> 
> I''ve got a patch-in-progress that will help the hub-power issue.
> 
> Letting a driver bind to devices would make things somewhat cleaner. 
It''s
> not implemented currently in the kernel; it''s one of the things
I''ve been
> considering adding.
Any idea how easy this would be?  Any chance of me being able to
implement a patch?
> 
> 
> > I''m still a bit confused by power management.  You say that
the hub does
> > device power management and the drivers do interface power
management...
> > 
> > Currently my back-end code is just a client of the normal linux USB
> > stack so, presumably the linux hub driver in the back-end will keep
> > doing whatever device power management it was doing before for the
> > devices that I''m exporting.  I''m not making any
explicit power
> > management calls for the devices in the back-end.
> > 
> > Any device power management in the front-end is also presumably done
by
> > the linux hub driver in the front-end and my front-end virtual hub
just
> > fakes it out or ignores it.
> > 
> > So, is this an OK solution for device power management?
> 
> I think it''s okay, except for that sticky point concerning remote
wakeup.
> As long as the front-end doesn''t try to do aggressive power
management
> (which Linux has not yet implemented) you should be fine.
> 
> > As far as interface power management goes, all I can find in the spec
is
> > a reference to another document describing the INTERFACE_POWER
> > descriptor which a bit of googling seems to indicate was withdrawn
from
> > the standard shortly after being released.
> > 
> > What exactly do you mean by interface power management?
> 
> It''s not really a formal USB term.  I mean notifying drivers
(which manage
> interfaces) about power management events.  Basically, a driver needs to 
> cancel all its URBs when the device is about to be suspended and resubmit 
> them when the device resumes.  In between, of course, it should not try to 
> submit any URBs.
> 
> > I''m assuming that anything the driver is doing to its
interface is done
> > by submitting an URB in the front-end which will be forwarded to the
> > back-end and submitted to the back-end device interface.  Since the
> > back-end driver is not submitting any of its own URBs there should be
no
> > interference between back and front-end drivers for any interface
power
> > management.
> > 
> > Is this correct?
> 
> There should be no interference provided the back-end doesn''t try
to
> suspend any devices all by itself.  To protect against that possibility,
> your stub driver should be written so that its suspend method sends the
> front-end a virtual disconnect event and its resume method sends a virtual
> connect event.  That''s probably about the same as what the probe
and
> disconnect methods do now.
OK.
> 
> (I expect you''re careful about sending these connect and
disconnect
> events for devices with multiple interfaces.  Like, send them only the 
> _first_ time an interface is probed/resumed and the _last_ time an 
> interface is disconnected/suspended.)
The code currently claims all the interfaces of a device when the first
interface of the device is probed and releases them all when the first
interface of the device is released:

+int usbback_driver_port_probe_usb(struct usb_interface *intf)
+{
+	int return_value = 0, i;
+	struct usb_device *usbdev = interface_to_usbdev(intf);
+	struct usbback_driver_port *port = NULL, *cur = NULL;
+	trace();
+	printk(KERN_INFO "usbback: Probe for usb device %s\n",
+							usbdev->devpath);
+	down_read(&usbback_driver_port_list_sem);
+	list_for_each_entry(cur, &usbback_driver_port_list, link) {
+		printk(KERN_INFO "usbback: Testing configured path %s:",
+								cur->path);
+		if (strncmp(cur->path, usbdev->devpath, sizeof(cur->path))
+									== 0) {
+			printk(" matches.\n");
+			port = cur;
+			break;
+		} else {
+			printk(" doesn''t match.\n");
+		}
+	}
+	if (port == NULL) {
+		printk(KERN_INFO "usbback: No match found.\n");
+		return_value = -ENODEV;
+		goto exit_no_port;
+	}
+	for (i = 0; i < usbdev->actconfig->desc.bNumInterfaces; i++) {
+		struct usb_interface *other_intf = usb_ifnum_to_if(usbdev, i);
+		if (other_intf != intf) {
+			if (usb_interface_claimed(other_intf)) {
+				printk(KERN_INFO "usbback: An interface of the"
+					" matching device is already in use by"
+					" another driver.\n");
+				return_value = -EBUSY;
+				goto exit_interface_already_claimed;
+			}
+		}
+	}
+	for (i = 0; i < usbdev->actconfig->desc.bNumInterfaces; i++) {
+		struct usb_interface *other_intf = usb_ifnum_to_if(usbdev, i);
+		if (other_intf != intf) {
+			int error = usb_driver_claim_interface(
+				&usbback_driver_usb_driver, other_intf, port);
+			/* We already checked the interfaces were available. */
+			ASSERT(error == 0);
+		}
+	}
+	usbdev = usb_get_dev(usbdev);
+	usb_set_intfdata(intf, port);
+	spin_lock_irq(&port->lock);
+	port->usbdev_is_connected = 1;
+	port->usbdev = usbdev;
+	usbback_driver_port_handle_stimulus(port,
+					usbback_driver_port_stimulus_up);
+	spin_unlock_irq(&port->lock);
+ exit_interface_already_claimed:
+ exit_no_port:
+	up_read(&usbback_driver_port_list_sem);
+	return return_value;
+}
+
+void usbback_driver_port_disconnect_usb(struct usb_interface *intf)
+{
+	struct usbback_driver_port *port = usb_get_intfdata(intf);
+	trace();
+	/* Protect against reentrant call when we release other interfaces. */
+	if (port != NULL) {
+		struct usb_device *usbdev;
+		int i;
+		ASSERT(port->usbdev_is_connected);
+		spin_lock_irq(&port->lock);
+		port->usbdev_is_connected = 0;
+		port->enabled = 0;
+		port->usb_disconnect = 0;
+		usbback_driver_port_handle_stimulus(port,
+					usbback_driver_port_stimulus_ud);
+		spin_unlock_irq(&port->lock);
+		xenidc_work_until(port->usb_disconnect);
+		usbdev = port->usbdev;
+		for (i = 0; i < usbdev->actconfig->desc.bNumInterfaces; i++) {
+			struct usb_interface *other_intf = usb_ifnum_to_if(
+								usbdev, i);
+			if (other_intf != intf) {
+				/* Protect against reentrant call when we    */
+				/* release other interfaces.                 */
+				usb_set_intfdata(other_intf, NULL);
+				usb_driver_release_interface(
+						&usbback_driver_usb_driver,
+								other_intf);
+			}
+		}
+		usb_set_intfdata(intf, NULL);
+		usb_put_dev(usbdev);
+	}
+}
> 
> > So, I think the power management strategy for my current code might be
> > reasonable.
> > 
> > Can you still see anything wrong with it?
> 
> So long as you can ignore the remote wakeup problem, you should be good.
Good enough for the time being.  Eventually the power management can be
virtualized.

Many thanks for all your help.  I have a fair amount of work to do to
fix the protocol issues for unlinking and resubmitting URBs.  I''ll
probably resurface in Jan.

Harry.

-- 
Harry Butterworth <harry@hebutterworth.freeserve.co.uk>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

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.

Who knows, vmware could probably also use this to help their
implementation out, if they want to write GPL code :)

thanks,

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2005-12-08 at 16:44 -0800, 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.)
> 
> 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.
OK.  I think I''d like to pursue this.  I want to fix my error recovery
and write some documentation so I''ll probably get back to it in Jan
unless I get reassigned to something else.

I''m not sure if I''m going to be capable of putting a patch
together.  It
depends just how hairy it turns out to be.  Any chance you could list
the issues that you know would need to be solved.  This would be a great
help when I come to look at it.

Harry.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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@lists.xensource.com
http://lists.xensource.com/xen-devel

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@lists.sourceforge.net
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
> 
-- 
Harry Butterworth <harry@hebutterworth.freeserve.co.uk>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 9 Dec 2005, Harry Butterworth wrote:
> 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.
It is already possible.  Something like this:

	echo -n 1-2:1.0 >/sys/bus/usb/drivers/[driver]/unbind

Or it can be done using usbfs.  And if you want to do it from within the 
kernel, call device_release_driver(dev).

Alan Stern


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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@lists.xensource.com
http://lists.xensource.com/xen-devel