Re: [PATCH 5 of 5] blkif.h: Define and document the request number/size/segments extension

[Keir Fraser <keir.xen@gmail.com>]

On 08/02/2012 07:48, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 07.02.12 at 14:49, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 07/02/2012 21:45, "Justin Gibbs" <justing@spectralogic.com> wrote:
>> 
>>>  1. Version the header file and require consumers to declare the interface
>>> version
>>>      they are using.  If the version isn't declared, the default, legacy,
>>> "version 1.0" will
>>>      be in effect.
>>> 
>>>      Positives:   No change in or constant naming conventions.  Data
>>> structures and
>>>                          constants for new features are properly hidden from
>>> legacy implementations.
>>>      Negatives: Messy #ifdefs
>> 
>> We already have this. See use of
>> __XEN_INTERFACE_VERSION__/__XEN_LATEST_INTERFACE_VERSION__ in the public
>> headers.
> 
> Hmm, I would think these should specifically not be used in the
> io/ subtree - those aren't definitions of the interface to Xen, but
> ones shared between the respective backends and frontends.
> Each interface is (apart from its relying on the ring definitions)
> entirely self contained.

I guess I think of the whole header set under xen/include/public as one
unit, versioned by __XEN_INTERFACE_VERSION__. And that's how users are
generally syncing with our headers -- copy them in their entirety over the
top of the old ones.

I'm not over fussed which solution you agree on in this specific case
however.

 -- Keir

> Jan
>