[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

>>>> On 07.02.12 at 14:49, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
>> On 07/02/2012 21:45, "Justin Gibbs" <justing@xxxxxxxxxxxxxxxx> 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
>> 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

 -- Keir

> Jan

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.