This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: usbback cleanup code

> I don't think the other drivers are expressed in a way that allows the
> reader to see that they are obviously correct.  I found them fairly
> difficult to read and I think they could be improved with some
> additional internal structure.

Agreed, up to a point.  Certainly Xenbus interfacing used to feel a little 
like voodoo, but I do believe it has improved.  It can probably get better 
still.  The data-path part of the other drivers generally seemed reasonably 
readable to me, although I admit it did take a bit of head scratching to 
understand why sometimes.

What I do like about those drivers is that because the code volume is small 
and they have very few files, it's quite easy to see how things fit together, 
if not clearly understand all the nuances.

> > I didn't have time to study the code in detail, but I
> > wasn't convinced they were all strictly necessary.
> This feedback isn't specific enough to be useful for me to improve the
> patches to your liking.

No, sorry about that.

I might be able to find time to look through the patch in more detail to see 
what specifically I think needs doing.  If I gave more specific feedback, 
would you be willing to take another pass?  Doing so ought to move us a step 
forwards, at least.

> > Any reason not just to fail all the URBs on the queue?
> There was some discussion about this on the USB mailing list.
> Apparently the URBs on the control endpoint can have more than one
> source (presumably the USB stack and the USB driver) and failure for one
> client shouldn't impact another client.

Good point!  It's interesting...  Kudos for extracting this arcane wisdom from 
the USB developers  ;-)  It makes sense...  the USB stack can send generic 
enumeration, address setting, etc messages to the device but it's also 
perfectly valid for the client driver to use control messages - possibly 
*only* control messages, e.g. for a HID device.

I'd suggest that failing them all is fine for now, and then look at improving 
it later.  I don't imagine it's going to be a common scenario, and would 
suggest that we're better having an in-tree driver that can be improved as we 


Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Xen-devel mailing list