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