WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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