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

[Keir Fraser <keir.xen@gmail.com>]

On 09/02/2012 01:25, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 09.02.12 at 07:22, "Justin T. Gibbs" <justing@spectralogic.com> 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
> 
> 
>