Re: [Xen-devel] USB Xen Summit status summary

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

Hi Nivedita,

Thanks for the summary, sounds good.

> 2. Harry puts out a simpler USB driver without his IDC
>     API, written directly to the current Xen bus/store API,
>     and reducing to only features deemed needed for Xen,
>     see if that will be accepted into tree.

This would be my preference, as a first step.  We don't want to lose the 
benefits of having a better abstraction layer, either, but it would be good 
to revisit that later.

> 4. Throw away everything and have someone else rewrite
>     from scratch.

Probably unnecessary, and we really ought to benefit from the debugging of 
interacting with USB subtleties that has gone into this code.

> - IDC piece very unlikely to be accepted into Linux mainline,
>    hence should not go into Xen tree

If it were used more generally as an abstraction layer for Xen drivers it 
seems to me acceptance upstream shouldn't be such a problem.  Ideally, we'd 
probably want some way of converting old drivers to new and better 
abstractions without breaking ABIs - I guess this really comes under the 
heading of incorporating the concepts into the XenBus code.

Harry has also mentioned the possibility of allowing networked implementations 
of driver interfaces: saves us from having to use 3rd party network protocols 
(like the USBoIP work) when migrating, etc.  It'd be nice if we could at 
least maintain the backend in such a way that adding this wouldn't be too 
painful.  Local access is far more important though - we can always figure 
out ways to export stuff over the network based on this.

> - API code is orthogonal to USB driver piece, should be
>    a seperate patch/discussion [consensus]

Yes.  It's more work to do this, but good to be able to tackle stuff in 
smaller chunks.

> - Best option is (2), rewrite code to leaner, simpler
>    USB driver with minimal functionality, and get that into
>    tree
> - Noone in session had looked at USBoverIp patches

The USBoIP patches seem to be rather full-featured, and they do support 
isochronous transfers (I don't think the Xen USB driver supports this 
anymore, but it used to in the 2.4 days and there is code in the original 
patches that could be brought back).  However, I don't relying on IP for USB 
is a good idea, and rewriting the USBoIP driver to use local transfers 
doesn't necessarily seem any easier than rewriting the other code.

> - There were some good ideas in the IDC API that needed
>    to be discussed/incorporated in Xen

Yep.

> - Need to get USB community input

Harry has been doing this recently, I believe.

> - Keir: rewrite to a simpler driver without the IDC API
>    as the xenbus/store stuff is pretty baked into Xen now,
>    might want to do some cleanups in this area.

It seems to me that integration with XenStore will offer opportunities to 
improve XenStore / XenBus concurrently.

> - Ian: look at USBoverIP, tried it and it seems to
>    work, but not sure if that's the right solution

Agreed.

> Current Issues/Design questions:
> - Harry's code supports back/front module load/unload
>    (useful during development, if nothing else).

Would be nice to keep this functionality - and extend to other devices.  But 
probably not critical, unless it really speeds up development a lot.

> - What other code functionality can be dropped in order
>    to make it smaller?

I don't think having complete USB functionality is mutually exclusive with the 
driver being *reasonably* small, especially with the 2.6 kernel USB client 
API.

Cheers,
Mark

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