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
