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:44:42 -0800 Message-ID: References: <4F339F0A0200007800071D46@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F339F0A0200007800071D46@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 T. Gibbs" Cc: "" List-Id: xen-devel@lists.xenproject.org On 09/02/2012 01:25, "Jan Beulich" wrote: >>>> On 09.02.12 at 07:22, "Justin T. Gibbs" wrote: > >> On Feb 8, 2012, at 12:48 AM, Jan Beulich wrote: >>> >>> 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. >>> >>> Jan >> >> >> 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") > > Sure. But pulling in header updates should not require *any* other > source changes, so long as __XEN_INTERFACE_VERSION__ isn't > bumped. > > My point about not using __XEN_INTERFACE_VERSION__ under io/ > is that these declare protocols that the hypervisor is completely > unaware of, whereas the constant really is meant to control > compatibility with hypervisor changes. In particular is this or any > other change to the protocols under io/ entirely unrelated to the > particular hypervisor version (and hence its interface revision). Actually __XEN_INTERFACE_VERSION__ is simply versioning the *source-level API* exposed by those headers. It's not really directly linked to versioning of the hypervisor ABI, after all that has to ensure backward compatibility whatever we do. Perhaps __XEN_INTERFACE_VERSION__ is simply badly named. -- Keir > It's also unclear to me why simply giving new constants new names > (instead of changing the meaning of existing ones) is such a big > deal - the most strait forward solution doubtlessly is not having > any conditionals in that header, and simply add new things with > new, unambiguous names. > > Jan > >> 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. >> >> -- >> Justin > > >