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

[Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

On Thu, 2006-02-02 at 08:51 -0600, Anthony Liguori wrote:
> Harry Butterworth wrote:
> 
> >Would someone please explain why people thought the xenidc code is
> >unlikely to get accepted into mainline?
> >
> It's the sheer volume of code.  The size of your xenidc patch is on par 
> with early versions of the hypervisor in terms of SLOCs.
> 
> Abstractions without a clear need for the abstraction is heavily frowned 
> upon in Linux.  It's just way too much code without a compelling 
> justification for what it's needed.

Ignoring the current xenidc implementation for the time being, I think
the justification for a high level IDC API is that it should...

o - allow you to express the drivers more simply, with less code and
independent of the memory management architecture.
o - allow you to have one instance of the code for the low-level
operations that are common between drivers and likely to need changing
in the future.
o - provide you with a framework to help write drivers that correctly
handle the domain and driver module lifecycles and the resource
management issues of inter-domain communication.
o - allow you to express the device protocols independent of the memory
management architecture of any particular OS.
o - allow for future network transparent split-drivers.

Comparing the old blkback with the version I did against xenidc shows
that...

o - the xenidc version is smaller and independent of the memory
management architecture.
o - the xenidc version contains no low-level memory management
operations.
o - the xenidc version handles the domain and module lifecycles and
implements a robust resource management strategy (except where I didn't
bother to finish it).
o - the xenidc version has a protocol expressed independent of the
scatter gather form used by the linux block driver stack.
o - the xenidc version is compatible with a future network transparent
xenidc implementation.

There is quite a lot to get right to do a split driver well.  If we want
high quality split drivers we should invest the effort required to
provide a good API that is easy to use and encourages driver authors to
write good code.

I'm done arguing for xenidc.  As my first bit of Linux code I didn't
really expect to come up with something that people would actually like
anyway.

Hopefully I'll see some of the concepts get factored into the xen driver
infrastructure in the future.

Easy come.  Easy go.

Harry.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel