[PATCH 1/2] qemu_capabilities: Introduce QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID

[Igor Mammedov]

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. 

> I want to prevent that this commit will be used as an excuse to depend
> on experimental properties which are not actually considered
> non-experimental. 
>