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