On Mon, 2006-05-01 at 15:04 +0100, M.A. Williamson wrote:
> Harry,
>
> 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).
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.
> 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.
> Since the existing code is known to work, and
> has indentified a number of interesting corner cases this shouldn't be too
> hard. If anyone's interested, it'd require you to develop a knowledge of
> the USB protocols, the Linux USB stack, and the Xen driver APIs. The task
> would be a combination of refactoring existing code to satisfy merge
> review, restoring isochronous support (this is still broken, right?
Isochronous is implemented but untested as I couldn't get the
isochronous devices I bought for testing working under native Linux.
> Should
> be possible to implement some of the original code to get it up and running
> again), optimising performance and testing with real devices.
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.
Also I would expect the Linux USB stack to have changed again.
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
> >
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home