Re: [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP

[Thomas Huth <thuth@redhat.com>]

On 24/04/2019 20.10, Eduardo Habkost wrote:
> On Wed, Apr 24, 2019 at 09:56:53AM +0200, Thomas Huth wrote:
>> On 23/04/2019 23.22, Eduardo Habkost wrote:
>>> This series adds machine type deprecation information to the
>>> output of the `query-machines` QMP command.  With this, libvirt
>>> and management software will be able to show this information to
>>> users and/or suggest changes to VM configuration to avoid
>>> deprecated machine types.
>>>
>>> Eduardo Habkost (3):
>>>   qapi: SupportStatusInfo struct
>>>   machine: Use SupportStatusInfo for deprecation info
>>>   qmp: Add deprecation information to query-machines
>>>
>>>  qapi/common.json                   | 24 ++++++++++++++++++++++++
>>>  qapi/misc.json                     |  5 ++++-
>>>  include/hw/boards.h                |  7 ++++---
>>>  hw/i386/pc_piix.c                  |  4 +++-
>>>  hw/ppc/prep.c                      |  4 +++-
>>>  vl.c                               | 19 +++++++++++++++----
>>>  tests/acceptance/query_machines.py | 27 +++++++++++++++++++++++++++
>>>  7 files changed, 80 insertions(+), 10 deletions(-)
>>>  create mode 100644 tests/acceptance/query_machines.py
>>
>> Good idea, but some questions come to my mind:
>>
>> - What about devices? IIRC Gerd wrote a patch series last year that does
>>   something similar for devices... It would be good to synchronize the
>>   work, so that we do not have two completely interfaces between devices
>>   and machines here in the end...
> 
> My plan is to support this on devices, too.  I even had a version
> where documentation of SupportStatusInfo mentioned device types,
> but I decided to leave that out until we actually implement a
> device deprecation info API.
> 
>>
>> - Is deprecation as a status enough, or do we want to carry more
>>   information here? E.g. is the machine maintained or orphan? Is it
>>   stable or rather experimental? And didn't Gerd have also some
>>   patches for this last year? ... yes, I think it was this series here:
>>   http://lists.gnu.org/archive/html/qemu-ppc/2018-11/msg00039.html
>>   ... actually, I like that idea with QemuSupportState... maybe you
>>   could base your work on that series instead?
> 
> We might want to carry more information eventually.  The
> possibility of extending the data later is the main reason I
> called the struct SupportStatusInfo and not just DeprecationInfo.

Ok. I was just a little bit afraid that we define an interface here that
we have to change again completely once we want to carry more
information. For example whether "deprecated" should be a "bool" here,
or rather one of the "enum" entries like in Gerd's series. But after
reading through https://patchwork.kernel.org/patch/10660677/ again, I
think I agree that "deprecated" is orthogonal to the support state, e.g.
a device could still be supported (in the sense that there is a
maintainer for it), while it has been marked as "deprecated" already.
So no more objections from my side here.

 Thomas