On 2/17/21 12:07 AM, John Snow wrote:
On 2/16/21 5:23 PM, Eduardo Habkost wrote:
On Tue, Jan 26, 2021 at 08:48:25AM +0100, Michal Privoznik wrote:
When management applications (like Libvirt) want to check whether
memory-backend-file.pmem is supported they can list object
properties using 'qom-list-properties'. However, 'pmem' is
declared always (and thus reported always) and only at runtime
QEMU errors out if it was built without libpmem (and thus can not
guarantee write persistence). This is suboptimal since we have
ability to declare attributes at compile time.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1915216
Signed-off-by: Michal Privoznik <mpriv...@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb...@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb...@gmail.com>
Reviewed-by: Igor Mammedov <imamm...@redhat.com>
I'm not a fan of making availability of properties conditional
(even if at compile time), but if this helps libvirt I guess it
makes sense.
Compile time might be OK, but if we want to describe everything via QAPI
eventually, we just need to be able to describe that compile-time
requisite appropriately.
Conditional at run-time is I think the thing that absolutely has to go
wherever it surfaces.
I'm open for discussion. How do you think libvirt (or any other mgmt
tool/user) should inspect whether given feature is available?
What libvirt currently does it issues 'qom-list-properties' with
'typename=memory-backend-file' and inspects whether pmem attribute is
available. Is 'qom-list' preferred?
CCing John, who has been thinking a lot about these questions.
Thanks for the heads up. Good reminder that libvirt uses the existence
of properties as a bellwether for feature support. I don't think I like
that idea, but I like breaking libvirt even less.
That was at hand solution. If libvirt's not doing it right, I'm happy to
make things better.
Michal
