Re: Re: [patch/rfc] multiprotocol blkback drivers (32-on-64)

[Keir Fraser <keir@xensource.com>]

On 20/12/06 15:47, "Jan Beulich" <jbeulich@novell.com> 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