This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Anthony Liguori <aliguori@xxxxxxxxxx>
Subject: Re: [Xen-devel] USB Xen Summit status summary
From: Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 02 Feb 2006 18:42:20 +0000
Cc: Nivedita Singhvi <nsnix@xxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 02 Feb 2006 18:52:07 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <43E21C65.7020706@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <43E0E196.8090502@xxxxxxxxxxx> <1138820403.8012.113.camel@xxxxxxxxxxxxxxxxxxxxx> <43E21C65.7020706@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

o - the xenidc version is smaller and independent of the memory
management architecture.
o - the xenidc version contains no low-level memory management
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

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

Easy come.  Easy go.


Xen-devel mailing list