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

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> > I was able to do a little review of the patch a while back but never had
> > to time finish looking through it properly. It looked much closer to
> > mergeable, but there still seemed to be quite a lot of abstraction code.
> > I think in general, folks were hoping to see a minimum amount of
> > abstraction code with the USB driver instead using the driver APIs
> > correctly.
>
> As far as I'm aware, the USB code is using the driver API correctly
> (except possibly for any bugs or where the API may have changed since
> the last patch I released).

Sorry, didn't mean to imply it wasn't correctly using it now.  I meant to 
say "directly", which is not at all the same thing.

> I think we have a fairly fundamental disconnect about abstraction.  For
> me, abstraction is a necessary part of good software engineering.  Just
> as I assume you wouldn't write machine code where you could use assembly
> and wouldn't write assembly where you could write C, I wouldn't write
> code at a low level of abstraction where it was possible to use a higher
> level of abstraction.  Abstraction is useful to manage complexity and
> useful to write software which is easier to reason about and easier to
> modify.

Quite.  But it can be a problem where there's just one client, going through 
many layers of abstractions.

There were a lot of files added by your patch which appeared to be utility 
code / abstractions.  This is fine in general, but the other drivers seem to 
get away with much less of this kind of thing without suffering unduly in 
terms of complexity.  I didn't have time to study the code in detail, but I 
wasn't convinced they were all strictly necessary.

> > If you don't want to do any more work on it, then maybe it would make a
> > good project for somebody.
>
> If anyone wants to pick it up, they are more than welcome but I think it
> might be worthwhile to wait until some Xen drivers have been
> successfully merged upstream with Linux since I suspect that there may
> be some more significant churn in the xenbus/xenstore area before this
> happens.

Maybe, but I suspect upstream merge is still quite a long way off.

Personally, I've found that the Xenbus APIs are now sufficiently simple to 
work with that it's very little work to establish a shared memory page (I 
hacked up one very quickly for DCSS), after which you don't have to worry 
about them anylonger.  I don't think keeping up with the control plane is 
prohibitive now, although it was at one stage.

> Isochronous is implemented but untested as I couldn't get the
> isochronous devices I bought for testing working under native Linux.

OK.

> The most difficult remaining work is to fix the protocol to correctly
> stall URBs during error recovery.  I was involved in some discussion
> about this on the USB mailing list and there was a proposal for a
> solution but it is fairly tricky.  Stalling URBs is required when there
> is a queue of URBs and an URB fails.  If the URBs are not stalled then
> they may be submitted to the device out-of-order which is a
> data-integrity exposure.

Any reason not just to fail all the URBs on the queue?  It's not the ideal 
response, but I wouldn't see a need to handle error recovery fully initially, 
although it'd be nice in the long run.

> Also I would expect the Linux USB stack to have changed again.

2.6's APIs do change fairly flexibly, but I don't remember there being any 
major changes to the USB stack for some time now.

Cheers,
Mark

> Harry.
>
> > Cheers,
> > Mark
> >
> > On May 1 2006, Harry Butterworth wrote:
> > >I haven't done any more work on the USB code since the last patch I
> > >posted to xen-devel.  There wasn't any feedback and it wasn't committed.
> > >I think people were too busy with the release.
> > >
> > >I have stopped working on USB.  I have done several versions now with no
> > >success at getting it merged.  I think it will be easier to see what is
> > >required once there are some examples of drivers that have been merged
> > >with Linux.
> > >
> > >On Sat, 2006-04-29 at 19:43 +0000, sanjay kumar wrote:
> > >> Hi Harry,
> > >> Do you know by what time the USB virtualization code will be commited
> > >> in the xen-unstable tree?
> > >>
> > >> Thanks,
> > >> Sanjay
> > >>
> > >> On 4/3/06, Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
> > >> wrote:
> > >>         The code is supposed to work with isochronous devices but it's
> > >>         untested
> > >>         so probably doesn't.
> > >>
> > >>         Harry.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> ----------------------
> > >> PhD Student, Georgia Tech
> > >> http://www.cc.gatech.edu/~ksanjay/
> > >
> > >_______________________________________________
> > >Xen-devel mailing list
> > >Xen-devel@xxxxxxxxxxxxxxxxxxx
> > >http://lists.xensource.com/xen-devel

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