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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.02.12 at 14:49, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 07/02/2012 21:45, "Justin Gibbs" <justing@xxxxxxxxxxxxxxxx> wrote:
> 
>>> NAK. No backwards incompatible changes allowed in public headers.
>> 
>> Sorry for the slow reply on this.  I've been experimenting with ways to keep
>> legacy
>> source compatibility.  After trying lots of things, testing the impact on an
>> existing blkfront
>> and blkback implementation, I think the best two options are:
>> 
>>  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.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel