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: Thu, 09 Feb 2012 04:32:08 -0800 Message-ID: References: <493FE9A7-2B9A-4744-8AB3-447ED7B86492@spectralogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <493FE9A7-2B9A-4744-8AB3-447ED7B86492@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 T. Gibbs" , Jan Beulich Cc: "" List-Id: xen-devel@lists.xenproject.org On 08/02/2012 22:22, "Justin T. Gibbs" wrote: > The versioning required allows a driver to declare, "I am compatible > with any source compatibility breaking changes up to version X of > the header file". Declaring support for the latest version does > not require that a driver implement the new extensions. Just one > constant needs to be renamed. So I don't see this as really altering > the interface between front and backends (i.e. it is not a "blkif2") > > If the xen-compat.h behavior is that you can safely import the > public headers so long as you do not bump __XEN_INTERFACE_VERSION__ > until after you have audited and adjusted for the #ifdef guarded > changes in the header files, then that is exactly what is needed > in blkif.h. That's what XEN_INTERFACE_VERSION is for, yes. -- Keir