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 22:45, Justin Gibbs <justing@xxxxxxxxxxxxxxxx> wrote:
> On Feb 3, 2012, at 6:34 AM, Jan Beulich wrote:
> 
>>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@xxxxxxxxxxxxxxxx> wrote:
>>> xen/include/public/io/blkif.h |  106 
> ++++++++++++++++++++++++++++++++++++++++-
>>> 1 files changed, 103 insertions(+), 3 deletions(-)
>>> 
>>> 
>>> Note: The definition of BLKIF_MAX_SEGMENTS_PER_REQUEST has changed.
>>>      Drivers must be updated to, at minimum, use
>>>      BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, before being compatible
>>>      with this header file.
>> 
>> 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
> 
>  2. Create a new constant BLKIF_MAX_SEGS_PER_REQUEST, have the two other
>      new constants (for header and segment block counts) use this 
> convention, and
>      leave BLKIF_MAX_SEGMENTS_PER_REQUEST alone (but marked DEPRECATED).
> 
>      Positives:   No #ifdefs.  Shorter names for these constants.
>      Negatives: Changes the existing constant naming convention for updated
>                          drivers.  Leaves BLKIF_MAX_SEGMENTS_PER_REQUEST, a 
> constant
>                          that should no longer be used, visible.
> 
> Do you have a preference or a suggested alternative?

I would personally prefer 2.

Jan


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