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

[Justin Gibbs <justing@spectralogic.com>]

On Feb 3, 2012, at 6:34 AM, Jan Beulich wrote:

>>>> On 03.02.12 at 06:24, "Justin T. Gibbs" <justing@spectralogic.com> 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?

Thanks,
Justin