Re: [Qemu-devel] [PATCH 1/3] qapi: SupportStatusInfo struct

[Eduardo Habkost]

On Thu, Apr 25, 2019 at 11:20:58AM -0300, Wainer dos Santos Moschetta wrote:
> Hi Eduardo,
> 
> 
> On 04/23/2019 06:22 PM, Eduardo Habkost wrote:
> > This struct will be used to represent support and deprecation
> > status of QEMU features.
> > 
> > Signed-off-by: Eduardo Habkost <address@hidden>
> > ---
> >   qapi/common.json | 24 ++++++++++++++++++++++++
> >   1 file changed, 24 insertions(+)
> > 
> > diff --git a/qapi/common.json b/qapi/common.json
> > index 99d313ef3b..b59d0dc66b 100644
> > --- a/qapi/common.json
> > +++ b/qapi/common.json
> > @@ -193,3 +193,27 @@
> >                'ppc64', 'riscv32', 'riscv64', 's390x', 'sh4',
> >                'sh4eb', 'sparc', 'sparc64', 'tricore', 'unicore32',
> >                'x86_64', 'xtensa', 'xtensaeb' ] }
> > +
> > +##
> > +# @SupportStatusInfo:
> > +#
> > +# Information on support status of a given feature
> > +# (e.g. machine type)
> > +#
> > +# @deprecated: if true, the given feature is deprecated and may be removed
> > +#              in future versions of QEMU according to the QEMU deprecation
> > +#              policy.
> 
> Eventually management software will need the know the QEMU version the
> feature is planed for removal. So makes sense to include a field to capture
> that information as well or do you expect it to be added (as a good
> practice) in the 'status-message'?

If we really want to provide extra information like version
numbers, adding a separate field sounds better than using
status-message.

But I'm not sure we really want to include this amount of detail
in the API.  Mentioning explicit version numbers could make
things more complex for downstream distributions of QEMU that
include backports and/or have a different deprecation policy.

I'd like to hear opinions from others.

-- 
Eduardo