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 :|
next prev 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: linkBe 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).