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

[Justin Gibbs <justing@xxxxxxxxxxxxxxxx>]

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?

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