[PATCH 1/2] qemu_capabilities: Introduce QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID

Michal Privoznik mprivozn at redhat.com
Tue Jan 12 11:41:47 UTC 2021


On 1/12/21 12:35 PM, Peter Krempa 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.
> 
> 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.
> 

Alight, fair enough. Let me fix that in v2.

Michal




More information about the libvir-list mailing list