[PATCH 1/2] qemu_capabilities: Introduce QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID

[Peter Krempa]

On Tue, Jan 12, 2021 at 19:20:58 +0100, Igor Mammedov wrote:
> On Tue, 12 Jan 2021 12:35:19 +0100
> Peter Krempa <pkrempa at redhat.com> wrote:
> 
> > On Tue, Jan 12, 2021 at 12:29:58 +0100, Michal Privoznik wrote:
> > > On 1/12/21 12:19 PM, Peter Krempa wrote:  
> > > > On Tue, Jan 12, 2021 at 09:29:49 +0100, Michal Privoznik wrote:  
> > > > > This capability tracks whether memory-backend-file has
> > > > > "x-use-canonical-path-for-ramblock-id" attribute. Introduced into
> > > > > QEMU by commit v4.0.0-rc0~189^2. While "x-" prefix is considered  
> > > > 
> > > > Please use a commit hash instead of this.
> > > >   
> > > > > experimental or internal to QEMU, the next commit justifies its
> > > > > use.  
> > > > 
> > > > NACK unless qemu adds a statement to their code and documentation that
> > > > the this property is considered stable despite the 'x-prefix' and you
> > > > add a link to the appropriate qemu upstream commit once it's done.
> > > > 
> > > > We don't want to depend on experimental stuff so we need a strong
> > > > excuse.
> > > >   
> > > 
> > > That's done in the next commit. Do you want me to copy it here too? I
> > > figured I'd put the justification where I'm actually setting the internal
> > > knob.  
> > 
> > Yes, because this is also mentioning the an 'x-' prefixed property. I
> > want to be absolutely clear in any places (including a comment in the
> > code, which you also should add into the capability code) that this is
> > extraordinary circumstance and that qemu is actually considering that
> > property stable.
> 
> the only reason to keep x- prefix in this case is to cause less issues for
> downstream QEMUs. Since this compat property is copied to their own machine types.
> If we keep prefix downstream doesn't have to do anything, if we rename it,
> then downstreams have to carry a separate patch that does the same for
> their old machine types. 

That would be okay if it's limited to past versions, but in this
instance it is not. Allowing x-prefixed properties for any future
release is a dangerous precedent. If we want to allow to detect the
capability also for future release, we must declare that it's for a very
particular reason and also that qemu will not delete it at will.

This is to prevent any future discussions of unwaranted usage of
x-prefixed properties in libvirt.