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: Wed, 08 Feb 2012 06:00:48 +0000 Message-ID: References: <4F3236C70200007800071AA1@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F3236C70200007800071AA1@nat28.tlf.novell.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: Jan Beulich , Justin Gibbs Cc: "" List-Id: xen-devel@lists.xenproject.org On 08/02/2012 07:48, "Jan Beulich" wrote: >>>> On 07.02.12 at 14:49, Keir Fraser wrote: >> On 07/02/2012 21:45, "Justin Gibbs" wrote: >> >>> 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. I guess I think of the whole header set under xen/include/public as one unit, versioned by __XEN_INTERFACE_VERSION__. And that's how users are generally syncing with our headers -- copy them in their entirety over the top of the old ones. I'm not over fussed which solution you agree on in this specific case however. -- Keir > Jan >