Re: [PATCH v2 1/2] qemu_capabilities: Introduce QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID

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

 



On 1/14/21 2:10 PM, Peter Krempa wrote:
On Thu, Jan 14, 2021 at 13:52:45 +0100, Peter Krempa wrote:
On Thu, Jan 14, 2021 at 13:37:23 +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 fa0cb34d2210cc749b9a70db99bb41c56ad20831. While
"x-" prefix is considered experimental or internal to QEMU, the
next commit justifies its use.

Since the detection of this feature is not limited to existing qemus, my
requirement that qemu must add acknowledgement that
"x-use-canonical-path-for-ramblock-id" will be treated as a stable
feature from now on and the qemu commit adding that must be mentioned in
this commit.

Is there something concrete you have on mind that you want me to write there? I thought I added a comment around capability detection that justifies its use.


The only other way is to limit the feature detection to any released
qemu (thus qemu-5.2 and previous), since we still will not get a
guarantee that they will not change the flag in the future.

Let me reiterate the options when this will be acceptable so that we are
in the clear:

1) qemu declares "x-use-canonical-path-for-ramblock-id" stable in code
    and docs (please cc me on the commit)

I've linked that patch in the cover letter. It was sent already so a little too late to CC anybody, sorry


2) qemu drops the "x-", and ...
     2a) we use "use-canonical-path-for-ramblock-id" only with new qemus
         which have the stable version
         (this is what we would usually do)

Since I'm failing to document our use of this knob maybe this is the way to go.

     2b) we also add support for "x-use-canonical-path-for-ramblock-id"
         but detection will be limited to existing releases

Supporting "x-use-canonical-path-for-ramblock-id" for any future release
of qemu without a clear declaration that it's considered stable in qemu
is not acceptable for libvirt.


I think that's what the qemu patch I'm linking in the cover letter does.

Michal




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux