All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org, pkrempa@redhat.com, ehabkost@redhat.com,
	Peter Xu <peterx@redhat.com>,
	armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH v6 05/11] qapi: introduce new cmd option "allowed-in-preconfig"
Date: Tue, 1 May 2018 16:57:39 +0200	[thread overview]
Message-ID: <20180501165739.4a680341@redhat.com> (raw)
In-Reply-To: <f62a4655-2d55-dfc7-e332-3da3ce379c56@redhat.com>

On Fri, 27 Apr 2018 17:05:30 -0500
Eric Blake <eblake@redhat.com> wrote:

> On 04/27/2018 10:05 AM, Igor Mammedov wrote:
> > New option will be used to allow commands, which are prepared/need
> > to run, during preconfig state. Other commands that should be able
> > to run in preconfig state, should be ameded to not expect machine  
> 
> s/ameded/amended/
> 
> > in initialized state or deal with it.
> > 
> > For compatibility reasons, commands that don't use new flag
> > 'allowed-in-preconfig' explicitly are not permitted to run in
> > preconfig state but allowed in all other states like they used
> > to be.
> > 
> > Within this patch allow following commands in preconfig state:
> >    qmp_capabilities
> >    query-qmp-schema
> >    query-commands
> >    query-command-line-options
> >    query-status
> >    exit-preconfig
> > to allow qmp connection, basic introspection and moving to the next
> > state.
> > 
> > PS:
> > set-numa-node and query-hotpluggable-cpus will be enabled later in
> > a separate patches.
> > 
> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > ---
> > v6:
> >   * exclude 'cont' command from preconfig enabled, in favor of
> >     exit-preconfig command
> >   * makr exit-preconfig with allowed-in-preconfig=true  
> 
> s/makr/mark/ (not that the changelog matters to git...)
> 
> 
> > +++ b/docs/devel/qapi-code-gen.txt
> > @@ -559,7 +559,7 @@ following example objects:
> >  Usage: { 'command': STRING, '*data': COMPLEX-TYPE-NAME-OR-DICT,
> >           '*returns': TYPE-NAME, '*boxed': true,
> >           '*gen': false, '*success-response': false,
> > -         '*allow-oob': true }
> > +         '*allow-oob': true, '*allowed-in-preconfig': true }  
> 
> Bikeshedding - is it worth naming this just 'allow-preconfig', for a bit
> more similarity to 'allow-oob'?  It's less typing, and still conveys the
> same amount of information (allow preconfig to use this command).
Since I'll need to respin anyways, lets got with shorter name

> 
> >  
> >  Commands are defined by using a dictionary containing several members,
> >  where three members are most common.  The 'command' member is a
> > @@ -683,6 +683,14 @@ OOB command handlers must satisfy the following conditions:
> >  
> >  If in doubt, do not implement OOB execution support.
> >  
> > +A command may use optional 'allowed-in-preconfig' key to permit
> > +its execution at early runtime configuration stage (preconfig runstate).
> > +If not specified then a command defaults to 'allowed-in-preconfig: false'.  
> 
> Unusual spelling for JSON:
>  s/'allowed-in-preconfig: false'/'allowed-in-preconfig':false/
> 
> and of course, additional tweaks here and in other patches if you like
> my bikeshedding for a shorter name.
> 
> > +
> > +An example of declaring preconfig enabled command:  
> 
> Might read better as:
> An example of declaring a command that is enabled during preconfig:
> 
> > + { 'command': 'qmp_capabilities',
> > +   'allowed-in-preconfig': true }
> > +
> >  === Events ===
> >  
> >  Usage: { 'event': STRING, '*data': COMPLEX-TYPE-NAME-OR-DICT,
> > diff --git a/monitor.c b/monitor.c
> > index 0ffdf1d..e5e60dc 100644
> > --- a/monitor.c
> > +++ b/monitor.c
> > @@ -1183,7 +1183,7 @@ static void monitor_init_qmp_commands(void)
> >  
> >      qmp_register_command(&qmp_commands, "query-qmp-schema",
> >                           qmp_query_qmp_schema,
> > -                         QCO_NO_OPTIONS);
> > +                         QCO_ALLOWED_IN_PRECONFIG);  
> 
> I understand why query-qmp-schema is special cased (because it uses
> 'gen':false in QAPI), but...
> 
> >      qmp_register_command(&qmp_commands, "device_add", qmp_device_add,
> >                           QCO_NO_OPTIONS);
> >      qmp_register_command(&qmp_commands, "netdev_add", qmp_netdev_add,
> > @@ -1193,7 +1193,8 @@ static void monitor_init_qmp_commands(void)
> >  
> >      QTAILQ_INIT(&qmp_cap_negotiation_commands);
> >      qmp_register_command(&qmp_cap_negotiation_commands, "qmp_capabilities",
> > -                         qmp_marshal_qmp_capabilities, QCO_NO_OPTIONS);
> > +                         qmp_marshal_qmp_capabilities,
> > +                         QCO_ALLOWED_IN_PRECONFIG);  
> 
> ...why are we still special-casing the registration of qmp_capabilities
> here...
> 
> >  }
> >  
> >  static bool qmp_cap_enabled(Monitor *mon, QMPCapability cap)
> > diff --git a/qapi/introspect.json b/qapi/introspect.json
> > index c7f67b7..8036154 100644
> > --- a/qapi/introspect.json
> > +++ b/qapi/introspect.json
> > @@ -262,13 +262,16 @@
> >  # @allow-oob: whether the command allows out-of-band execution.
> >  #             (Since: 2.12)
> >  #
> > +# @allowed-in-preconfig: command can be executed in preconfig runstate,
> > +#                        default: 'false' (Since 2.13)
> > +#  
> 
> If we like the bikeshedding on the QAPI spelling, I think it also
> applies to the introspection spelling.
> 
> 
> > +++ b/qapi/misc.json
> > @@ -35,7 +35,8 @@
> >  #
> >  ##
> >  { 'command': 'qmp_capabilities',
> > -  'data': { '*enable': [ 'QMPCapability' ] } }
> > +  'data': { '*enable': [ 'QMPCapability' ] },
> > +  'allowed-in-preconfig': true }  
> 
> ...should't this be good enough to get qmp_capabilities registered?  Hmm
> - maybe that's an independent cleanup (and it might be missed fallout
> from Peter Xu's OOB work).
> 
> 
> > +++ b/scripts/qapi/common.py  
> 
> > @@ -1422,7 +1423,7 @@ class QAPISchemaAlternateType(QAPISchemaType):
> >  
> >  class QAPISchemaCommand(QAPISchemaEntity):
> >      def __init__(self, name, info, doc, arg_type, ret_type,
> > -                 gen, success_response, boxed, allow_oob):
> > +                 gen, success_response, boxed, allow_oob, allowed_in_preconfig):  
> 
> Borderline long line; I'd wrap it (except that if you use the shorter
> name allow_preconfig, then there's not a long line issue).
> 
> > +++ b/scripts/qapi/doc.py
> > @@ -226,8 +226,8 @@ class QAPISchemaGenDocVisitor(qapi.common.QAPISchemaVisitor):
> >                                 name=doc.symbol,
> >                                 body=texi_entity(doc, 'Members')))
> >  
> > -    def visit_command(self, name, info, arg_type, ret_type,
> > -                      gen, success_response, boxed, allow_oob):
> > +    def visit_command(self, name, info, arg_type, ret_type, gen,
> > +                      success_response, boxed, allow_oob, allowed_in_preconfig):
> >          doc = self.cur_doc
> >          if boxed:
> >              body = texi_body(doc)  
> 
> It's nice that introspection covers whether a command is allowed during
> preconfig; but wouldn't it also be nice if the documentation also
> mentioned this attribute?  (Hmm, partly my fault for missing during
> review of OOB that the same can be said about documentation of allow_oob
> - so you were just copying existing practice)
yep, it's pretty much copypast.
Could you point to a place/example commit that adds documentation?

> Overall looks reasonable to me, but see my notes elsewhere in the series
> about hoisting this earlier in the series while still keeping things
> compiling (perhaps by splitting the introduction of
> QCO_ALLOWED_IN_PRECONFIG from the introduction of --preconfig on the
> command line).
I'll fix the rest of comments and reshuffle series as you suggest here
and in previous review comments.

Thanks!

  parent reply	other threads:[~2018-05-01 14:57 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-27 15:05 [Qemu-devel] [PATCH v6 00/11] enable numa configuration before machine_init() from QMP Igor Mammedov
2018-04-27 15:05 ` [Qemu-devel] [PATCH v6 01/11] numa: postpone options post-processing till machine_run_board_init() Igor Mammedov
2018-04-27 15:05 ` [Qemu-devel] [PATCH v6 02/11] numa: split out NumaOptions parsing into set_numa_options() Igor Mammedov
2018-04-27 15:05 ` [Qemu-devel] [PATCH v6 03/11] cli: add --preconfig option Igor Mammedov
2018-04-27 21:44   ` Eric Blake
2018-05-01 15:07   ` Daniel P. Berrangé
2018-05-03 11:35     ` Igor Mammedov
2018-04-27 15:05 ` [Qemu-devel] [PATCH v6 04/11] hmp: disable monitor in preconfig state Igor Mammedov
2018-04-27 21:48   ` Eric Blake
2018-04-27 15:05 ` [Qemu-devel] [PATCH v6 05/11] qapi: introduce new cmd option "allowed-in-preconfig" Igor Mammedov
2018-04-27 22:05   ` Eric Blake
2018-04-28  3:51     ` Peter Xu
2018-04-30 14:49       ` Eric Blake
2018-05-01 14:57     ` Igor Mammedov [this message]
2018-05-01 15:29   ` Daniel P. Berrangé
2018-05-03 11:22     ` Igor Mammedov
2018-04-27 15:05 ` [Qemu-devel] [PATCH v6 06/11] tests: let qapi-schema tests detect allowed-in-preconfig Igor Mammedov
2018-04-27 22:08   ` Eric Blake
2018-04-27 22:12     ` Eric Blake
2018-04-27 15:05 ` [Qemu-devel] [PATCH v6 07/11] tests: add allowed-in-preconfig-test for qapi-schema Igor Mammedov
2018-04-27 22:11   ` Eric Blake
2018-04-27 15:05 ` [Qemu-devel] [PATCH v6 08/11] tests: extend qmp test with preconfig checks Igor Mammedov
2018-04-27 15:05 ` [Qemu-devel] [PATCH v6 09/11] qmp: permit query-hotpluggable-cpus in preconfig state Igor Mammedov
2018-04-27 15:05 ` [Qemu-devel] [PATCH v6 10/11] qmp: add set-numa-node command Igor Mammedov
2018-04-27 15:05 ` [Qemu-devel] [PATCH v6 11/11] tests: functional tests for QMP command set-numa-node Igor Mammedov

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=20180501165739.4a680341@redhat.com \
    --to=imammedo@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=peterx@redhat.com \
    --cc=pkrempa@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.