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] Re: [patch/rfc] multiprotocol blkback drivers (32-on-64)

To: Jan Beulich <jbeulich@xxxxxxxxxx>, Gerd Hoffmann <kraxel@xxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [patch/rfc] multiprotocol blkback drivers (32-on-64)
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Wed, 20 Dec 2006 16:07:40 +0000
Cc: Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 20 Dec 2006 08:07:35 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <45896929.76E4.0078.0@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcckUPkvN4V09pBEEduE2gAX8io7RQ==
Thread-topic: [Xen-devel] Re: [patch/rfc] multiprotocol blkback drivers (32-on-64)
User-agent: Microsoft-Entourage/
On 20/12/06 15:47, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> Looks a lot nicer now, except that I dislike the replication of the
> request/response
> structures in now three places. Besides possibly being a maintenance issue,
> this
> now seems worse in terms of scaling up to eventual future protocol versions. I
> had
> understood Keir in a much different way - adding a compiler abstraction header
> (which maybe could even make use of Linux' native ones) to include/xen, and
> making use of its abstraction directly in xen/include/public/io/blkif.h.

I quite like the explicitness of this approach. The duplication is small and
the structures aren't going to change (without changing protocol version
too) so maintenance is not that much of an issue. It would be nicer to put
the structure definition inside a macro, instantiated multiple times, or
inside another header file, included multiple times, though.

My other suggested approach is slightly hindered by the fact that all the
Xen public headers are include-only-once, although we could circumvent that
for this case I suppose. It's also questionable whether this can be done
really cleanly in a way that most compilers can adapt to -- do most have the
kind of flexible packing pragmas that GCC has?

Xen/include/public/io/blkif.h changes infrequently enough that we could
define linux/include/xen/blkif.h to be Linux's version and not include the
Xen-provided one directly at all. The Xen headers need Linux formatting
anyway, so it's not like the Linux blkif.h will ever be a direct copy of the
original Xen-provided blkif.h.

 -- Keir

Xen-devel mailing list