qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] fw_cfg: Allow reboot-timeout=-1 again


From: Markus Armbruster
Subject: Re: [PATCH] fw_cfg: Allow reboot-timeout=-1 again
Date: Fri, 01 Nov 2019 06:28:31 +0100

"Dr. David Alan Gilbert" <address@hidden> writes:

> * Han Han (address@hidden) wrote:
>> However, another important question is: how can we avoid such undocumented
>> incompatibility appears again?
>
> The reboot-timeout one was accidental - it was a documented qemu
> feature; just no one noticed it when the input check was added.

Yes.  Mistakes happen.  Integration tests can catch them.  Perfection is
impossible there as well, though.

> Officially if we actually want to deprecate a feature we should actually
> follow qemu's deprecation guidelines.

Yes.

>> I can show another case caused by such incompatibile change:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1745868#c0
>> 
>> For the qemu devices, attributes, values, qmp cmds, qmp cmds arguments used
>> by libvirt, could we get a way to inform libvirt
>> that an incompatibile qemu change is coming, please update libvirt code
>> ASAP to adjust to that change?
>> Or another way that is more gently:  popping up the warning of depreciation
>> instead of  dropping it, and then drop it in the version
>> after next version.
>
> Yes that should happen;

No argument.  The question is how.  I'm working on making it easier to
do and easier to consume for QAPI interfaces, i.e. most of QMP.

>                          with deprecated devices it's easier than more
> subtle features like command line things;  I'm not sure how that gets
> introspected.  I thought libvirt already asked qemu for a list of
> devices, so I'm confused why libvirt didn't spot it before starting the
> VM in 1745868.

Command line isn't really introspectable (see my KVM Forum 2017 talk).

That said, the list of devices *is* introspectable with QMP:

    {"execute": "qom-list-types",
     "arguments": {"implements": "device", "abstract": false}}

I'm not sure what exactly goes wrong in RHBZ 1745868.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]