qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: qemu-devel@nongnu.org, mprivozn@redhat.com,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/3] qapi: SupportStatusInfo struct
Date: Tue, 30 Apr 2019 13:47:40 +0100	[thread overview]
Message-ID: <20190430124740.GM6818@redhat.com> (raw)
In-Reply-To: <20190430124236.GC28722@habkost.net>

On Tue, Apr 30, 2019 at 09:42:36AM -0300, Eduardo Habkost wrote:
> On Tue, Apr 30, 2019 at 11:10:06AM +0100, Daniel P. Berrangé wrote:
> > On Wed, Apr 24, 2019 at 03:20:36PM -0300, Eduardo Habkost wrote:
> > > On Wed, Apr 24, 2019 at 09:26:52AM +0100, Daniel P. Berrangé wrote:
> > > > On Tue, Apr 23, 2019 at 06:22:44PM -0300, Eduardo Habkost wrote:
> > > > > This struct will be used to represent support and deprecation
> > > > > status of QEMU features.
> > > > > 
> > > > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > > > > ---
> > > > >  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.
> > > > > +#
> > > > > +# @status-message: Human readable message describing support status
> > > > > +#                  of the feature.
> > > > > +#
> > > > > +# @suggested-alternative: Optional.  Suggested alternative for a deprecated
> > > > > +#                         feature.  For machine types, this should be the name
> > > > > +#                         of an available machine-type.
> > > > > +#
> > > > > +# Since: 4.1
> > > > > +##
> > > > > +{ 'struct': 'SupportStatusInfo',
> > > > > +  'data': { 'deprecated': 'bool',
> > > > > +            '*status-message': 'str',
> > > > > +            '*suggested-alternative': 'str' } }
> > > > 
> > > > I see status-message has to be optional, since you're embedding the
> > > > struct into another struct and want deprecated==false by default.
> > > > 
> > > > I'd be inclined to change it to embed a pointer to the struct and
> > > > drop the deprecated field, and make both status-message and
> > > > suggested-alternative be mandatory. ie a struct  "DeprecationInfo" 
> > > > the pointer to which is NULL if not deprecated.
> > > 
> > > That could be a simple solution if we were sure we would only
> > > track deprecation info.  But I would like us to track additional
> > > support status on that struct eventually.
> > 
> > I've no objection to expanding it to capture other info - we'll
> > want to change the 'deprecated' field to an enum though. Also,
> > in some cases there won't be any real alternative so lets just
> > call it 'hint' instead. How about
> > 
> >     { 'enum':  "SupportStatus",
> >       'data': { 'production',  # Secure for use in hostile production env
> >                 'development', # No security guarentee, friendly dev only
> > 		'deprecated',  # To be removed in the future
> >     } }
> 
> "secure for production" and "deprecated" are independent
> variables.  There are deprecated features that are still secure,
> and deprecated features that were never supposed to be used in
> production in the first place.

Good point - we should track  quality status separately. So still
need a boolean deprecation flag too i guess. 

> 
> > 
> >     { 'struct': "SupportStatusInfo",
> >        'data': { 'status': 'SupportStatus',
> >                  '*info': 'str',
> > 		 '*hint': 'str' } }
> 
> "hint" seems nicer than "suggested" or "recommended".  I like it.
> 
> -- 
> Eduardo

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

WARNING: multiple messages have this Message-ID (diff)
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: mprivozn@redhat.com, qemu-devel@nongnu.org,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/3] qapi: SupportStatusInfo struct
Date: Tue, 30 Apr 2019 13:47:40 +0100	[thread overview]
Message-ID: <20190430124740.GM6818@redhat.com> (raw)
Message-ID: <20190430124740.kpSGggtM4IZdEHrZUQVkp-42JdrRsPcGbc2vb1RlQ3M@z> (raw)
In-Reply-To: <20190430124236.GC28722@habkost.net>

On Tue, Apr 30, 2019 at 09:42:36AM -0300, Eduardo Habkost wrote:
> On Tue, Apr 30, 2019 at 11:10:06AM +0100, Daniel P. Berrangé wrote:
> > On Wed, Apr 24, 2019 at 03:20:36PM -0300, Eduardo Habkost wrote:
> > > On Wed, Apr 24, 2019 at 09:26:52AM +0100, Daniel P. Berrangé wrote:
> > > > On Tue, Apr 23, 2019 at 06:22:44PM -0300, Eduardo Habkost wrote:
> > > > > This struct will be used to represent support and deprecation
> > > > > status of QEMU features.
> > > > > 
> > > > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> > > > > ---
> > > > >  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.
> > > > > +#
> > > > > +# @status-message: Human readable message describing support status
> > > > > +#                  of the feature.
> > > > > +#
> > > > > +# @suggested-alternative: Optional.  Suggested alternative for a deprecated
> > > > > +#                         feature.  For machine types, this should be the name
> > > > > +#                         of an available machine-type.
> > > > > +#
> > > > > +# Since: 4.1
> > > > > +##
> > > > > +{ 'struct': 'SupportStatusInfo',
> > > > > +  'data': { 'deprecated': 'bool',
> > > > > +            '*status-message': 'str',
> > > > > +            '*suggested-alternative': 'str' } }
> > > > 
> > > > I see status-message has to be optional, since you're embedding the
> > > > struct into another struct and want deprecated==false by default.
> > > > 
> > > > I'd be inclined to change it to embed a pointer to the struct and
> > > > drop the deprecated field, and make both status-message and
> > > > suggested-alternative be mandatory. ie a struct  "DeprecationInfo" 
> > > > the pointer to which is NULL if not deprecated.
> > > 
> > > That could be a simple solution if we were sure we would only
> > > track deprecation info.  But I would like us to track additional
> > > support status on that struct eventually.
> > 
> > I've no objection to expanding it to capture other info - we'll
> > want to change the 'deprecated' field to an enum though. Also,
> > in some cases there won't be any real alternative so lets just
> > call it 'hint' instead. How about
> > 
> >     { 'enum':  "SupportStatus",
> >       'data': { 'production',  # Secure for use in hostile production env
> >                 'development', # No security guarentee, friendly dev only
> > 		'deprecated',  # To be removed in the future
> >     } }
> 
> "secure for production" and "deprecated" are independent
> variables.  There are deprecated features that are still secure,
> and deprecated features that were never supposed to be used in
> production in the first place.

Good point - we should track  quality status separately. So still
need a boolean deprecation flag too i guess. 

> 
> > 
> >     { 'struct': "SupportStatusInfo",
> >        'data': { 'status': 'SupportStatus',
> >                  '*info': 'str',
> > 		 '*hint': 'str' } }
> 
> "hint" seems nicer than "suggested" or "recommended".  I like it.
> 
> -- 
> Eduardo

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


  parent reply	other threads:[~2019-04-30 12:47 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-23 21:22 [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP Eduardo Habkost
2019-04-23 21:22 ` Eduardo Habkost
2019-04-23 21:22 ` [Qemu-devel] [PATCH 1/3] qapi: SupportStatusInfo struct Eduardo Habkost
2019-04-23 21:22   ` Eduardo Habkost
2019-04-23 22:23   ` Philippe Mathieu-Daudé
2019-04-23 22:23     ` Philippe Mathieu-Daudé
2019-04-24 18:24     ` Eduardo Habkost
2019-04-24 18:24       ` Eduardo Habkost
2019-04-24  8:26   ` Daniel P. Berrangé
2019-04-24  8:26     ` Daniel P. Berrangé
2019-04-24 18:20     ` Eduardo Habkost
2019-04-24 18:20       ` Eduardo Habkost
2019-04-30 10:10       ` Daniel P. Berrangé
2019-04-30 10:10         ` Daniel P. Berrangé
2019-04-30 12:42         ` Eduardo Habkost
2019-04-30 12:42           ` Eduardo Habkost
2019-04-30 12:47           ` Daniel P. Berrangé [this message]
2019-04-30 12:47             ` Daniel P. Berrangé
2019-04-25 14:20   ` Wainer dos Santos Moschetta
2019-04-25 14:20     ` Wainer dos Santos Moschetta
2019-04-25 17:42     ` Eduardo Habkost
2019-04-25 17:42       ` Eduardo Habkost
2019-04-30 10:03       ` Daniel P. Berrangé
2019-04-30 10:03         ` Daniel P. Berrangé
2019-04-23 21:22 ` [Qemu-devel] [PATCH 2/3] machine: Use SupportStatusInfo for deprecation info Eduardo Habkost
2019-04-23 21:22   ` Eduardo Habkost
2019-04-23 22:26   ` Philippe Mathieu-Daudé
2019-04-23 22:26     ` Philippe Mathieu-Daudé
2019-04-24  1:37   ` David Gibson
2019-04-24  1:37     ` David Gibson
2019-04-24  8:23   ` Daniel P. Berrangé
2019-04-24  8:23     ` Daniel P. Berrangé
2019-04-24 18:29     ` Eduardo Habkost
2019-04-24 18:29       ` Eduardo Habkost
2019-04-23 21:22 ` [Qemu-devel] [PATCH 3/3] qmp: Add deprecation information to query-machines Eduardo Habkost
2019-04-23 21:22   ` Eduardo Habkost
2019-04-24  8:28   ` Daniel P. Berrangé
2019-04-24  8:28     ` Daniel P. Berrangé
2019-04-25 14:54   ` Wainer dos Santos Moschetta
2019-04-25 14:54     ` Wainer dos Santos Moschetta
2019-04-25 17:43     ` Eduardo Habkost
2019-04-25 17:43       ` Eduardo Habkost
2019-04-23 21:28 ` [Qemu-devel] [PATCH 0/3] Export machine type deprecation info through QMP no-reply
2019-04-23 21:28   ` no-reply
2019-04-24  7:56 ` Thomas Huth
2019-04-24  7:56   ` Thomas Huth
2019-04-24  8:31   ` Daniel P. Berrangé
2019-04-24  8:31     ` Daniel P. Berrangé
2019-04-24 18:14     ` Eduardo Habkost
2019-04-24 18:14       ` Eduardo Habkost
2019-04-24 18:10   ` Eduardo Habkost
2019-04-24 18:10     ` Eduardo Habkost
2019-04-25  7:38     ` Thomas Huth
2019-04-25  7:38       ` Thomas Huth
2019-04-30 10:11     ` Daniel P. Berrangé
2019-04-30 10:11       ` Daniel P. Berrangé
2019-04-24  8:23 ` Michal Privoznik
2019-04-24  8:23   ` Michal Privoznik
2019-05-07  5:07 ` Markus Armbruster
2019-05-07 16:18   ` Eduardo Habkost
2019-05-08  9:16     ` Markus Armbruster
2019-05-08 20:28       ` Eduardo Habkost
2019-05-09  8:31         ` Markus Armbruster
2019-05-09  9:14           ` Daniel P. Berrangé
2019-05-09 15:52             ` Eduardo Habkost
2019-05-09 16:08               ` Daniel P. Berrangé
2019-05-09 17:44                 ` Eduardo Habkost
2019-05-10  6:28                   ` Markus Armbruster
2019-05-10 17:03                     ` Eduardo Habkost
2019-05-10  6:19               ` Markus Armbruster
2019-05-10 17:00                 ` Eduardo Habkost
2019-05-09 18:19           ` Eduardo Habkost
2019-05-10  9:29             ` Markus Armbruster
2019-05-10 17:17               ` Eduardo Habkost
2019-05-10 17:26                 ` Daniel P. Berrangé
2019-05-13 11:49                 ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190430124740.GM6818@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=mprivozn@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).