[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen Project policy on feature flags



>>> On 26.09.14 at 15:24, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> I am writing to request a clarification on Xen feature flags
> (XENFEAT_*) and backward compatibility:
>     
> is the hypervisor allowed to remove any feature flags in a future
> release, even though doing so might break some existing guests?
> 
> For example one could write a PV on HVM guest that requires
> XENFEAT_hvm_callback_vector (regardless of PVH), could a future Xen
> release remove that feature? Or is it now part of our ABI, therefore
> maintained for backward compatibility, following the rule that we don't
> break existing guests?
> 
> 
> I always thought that any XENFEAT feature flags could be removed going
> forward, if the hypervisor maintainers decide to do so. However Ian
> Campbell is of the opposite opinion, so I think we should have a clear
> policy regarding them.
> 
> In any case I think that it is generally useful to have optional flags
> that advertise the presence of a feature but can also be removed going
> forward. If XENFEAT feature flags are not them, then we might still want
> to introduce them as a separate concept.

My view is that these are precisely there to indicate what the
hypervisor supports. I.e. while we can't remove the definition
from the public header, the hypervisor could stop advertising that
it's capable of a certain feature at any time. Consumers are
expected to check for the feature flag and deal with it being off.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.