From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 5 of 5] blkif.h: Define and document the request number/size/segments extension Date: Tue, 07 Feb 2012 13:49:18 +0000 Message-ID: References: <7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <7FAA6F15-2ECE-403F-A115-9687299A8BE7@spectralogic.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Justin Gibbs , Jan Beulich Cc: "" List-Id: xen-devel@lists.xenproject.org On 07/02/2012 21:45, "Justin Gibbs" 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. -- Keir