qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
	pkrempa@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v7 04/11] hmp: disable monitor in preconfig state
Date: Fri, 25 May 2018 16:39:34 -0300	[thread overview]
Message-ID: <20180525193934.GN8988@localhost.localdomain> (raw)
In-Reply-To: <87603cxob9.fsf@dusky.pond.sub.org>

On Fri, May 25, 2018 at 08:05:30AM +0200, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost@redhat.com> writes:
> 
> > On Thu, May 24, 2018 at 08:16:20PM +0200, Markus Armbruster wrote:
> >> Markus Armbruster <armbru@redhat.com> writes:
> >> 
> >> > Igor Mammedov <imammedo@redhat.com> writes:
> >> >
> >> >> Ban it for now, if someone would need it to work early,
> >> >> one would have to implement checks if HMP command is valid
> >> >> at preconfig state.
> >> >>
> >> >> Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> >> >> Reviewed-by: Eric Blake <eblake@redhat.com>
> >> >> ---
> >> >> v5:
> >> >>   * add 'use QMP instead" to error message, suggesting user
> >> >>     the right interface to use
> >> >> v4:
> >> >>   * v3 was only printing error but not preventing command execution,
> >> >>     Fix it by returning after printing error message.
> >> >>     ("Dr. David Alan Gilbert" <dgilbert@redhat.com>)
> >> >> ---
> >> >>  monitor.c | 6 ++++++
> >> >>  1 file changed, 6 insertions(+)
> >> >>
> >> >> diff --git a/monitor.c b/monitor.c
> >> >> index 39f8ee1..0ffdf1d 100644
> >> >> --- a/monitor.c
> >> >> +++ b/monitor.c
> >> >> @@ -3374,6 +3374,12 @@ static void handle_hmp_command(Monitor *mon, const char *cmdline)
> >> >>  
> >> >>      trace_handle_hmp_command(mon, cmdline);
> >> >>  
> >> >> +    if (runstate_check(RUN_STATE_PRECONFIG)) {
> >> >> +        monitor_printf(mon, "HMP not available in preconfig state, "
> >> >> +                            "use QMP instead\n");
> >> >> +        return;
> >> >> +    }
> >> >> +
> >> >>      cmd = monitor_parse_command(mon, cmdline, &cmdline, mon->cmd_table);
> >> >>      if (!cmd) {
> >> >>          return;
> >> >
> >> > So we offer the user an HMP monitor, but we summarily fail all commands.
> >> > I'm sorry, but that's... searching for polite word... embarrassing.  We
> >> > should accept HMP output only when we're ready to accept it.  Yes, that
> >> > would involve a bit more surgery rather than this cheap hack.  The whole
> >> > preconfig thing smells like a cheap hack to me, but let's not overdo it.
> >> 
> >> Clarification: I don't think we need to hold the series because of
> >> this.  I do think you should investigate delaying HMP until it can work.
> >
> > What would it mean to delay HMP?  Not creating the socket?
> > Creating the socket but not accepting clients?  Accepting clients
> > but not consuming any input from the socket until we are out of
> > preconfig?
> >
> > I'm not sure if any of those options would be better.  If a human
> > is already trying to talk on the other side, it seems better to
> > show QEMU is alive (but not ready to hold a conversation yet)
> > than staying silent.
> 
> If this
> 
>     QEMU 2.12.50 monitor - type 'help' for more information
>     (qemu) help
>     HMP not available in preconfig state, use QMP instead
>     (qemu) quit
>     HMP not available in preconfig state, use QMP instead
>     (qemu) let me out dammit
>     HMP not available in preconfig state, use QMP instead
>     (qemu) 
> 
> is better than the alternatives, then I wonder how much more
> entertainment the alternatives could provide!
> 
> We *can* do better.  Start like this:
> 
>     QEMU 2.12.50 monitor is not ready with -preconfig until you complete
>     configuration with QMP
> 
> and when we exit preconfig state, add:
> 
>     QEMU 2.12.50 monitor - type 'help' for more information
>     (qemu) 
> 
> Note that this is upfront about the monitor not being ready, avoids
> misleading the user about "help", talks to the user in the user's terms
> (-preconfig) instead of internal terms (preconfig state), and is more
> specific on how to ready the monitor.

Yes, this sounds better than any of the options I have
considered.

Making at least 'help', 'quit', and 'exit-preconfig' work might
be even better, though.

-- 
Eduardo

  reply	other threads:[~2018-05-25 19:39 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-04  8:37 [Qemu-devel] [PATCH v7 00/11] enable numa configuration before machine_init() from QMP Igor Mammedov
2018-05-04  8:37 ` [Qemu-devel] [PATCH v7 01/11] numa: postpone options post-processing till machine_run_board_init() Igor Mammedov
2018-05-16 18:12   ` Eduardo Habkost
2018-05-04  8:37 ` [Qemu-devel] [PATCH v7 02/11] numa: split out NumaOptions parsing into set_numa_options() Igor Mammedov
2018-05-16 18:12   ` Eduardo Habkost
2018-05-04  8:37 ` [Qemu-devel] [PATCH v7 03/11] qapi: introduce preconfig runstate Igor Mammedov
2018-05-11 15:17   ` Eric Blake
2018-05-16 18:14   ` Eduardo Habkost
2018-05-04  8:37 ` [Qemu-devel] [PATCH v7 04/11] hmp: disable monitor in preconfig state Igor Mammedov
2018-05-24 16:00   ` Markus Armbruster
2018-05-24 18:16     ` Markus Armbruster
2018-05-24 18:26       ` Eduardo Habkost
2018-05-25  6:05         ` Markus Armbruster
2018-05-25 19:39           ` Eduardo Habkost [this message]
2018-05-28  9:31             ` Igor Mammedov
2018-06-01  8:59               ` Dr. David Alan Gilbert
2018-05-04  8:37 ` [Qemu-devel] [PATCH v7 05/11] qapi: introduce new cmd option "allowed-in-preconfig" Igor Mammedov
2018-05-11 15:26   ` Eric Blake
2018-05-11 16:56     ` Igor Mammedov
2018-05-11 16:51   ` [Qemu-devel] [PATCH v8 05/11] qapi: introduce new cmd option "allow-preconfig" Igor Mammedov
2018-05-11 17:16     ` Eric Blake
2018-05-04  8:37 ` [Qemu-devel] [PATCH v7 06/11] tests: qapi-schema tests for allow-preconfig Igor Mammedov
2018-05-11 15:29   ` Eric Blake
2018-05-16 18:16     ` Eduardo Habkost
2018-05-11 17:15   ` [Qemu-devel] [PATCH v8 " Igor Mammedov
2018-05-04  8:37 ` [Qemu-devel] [PATCH v7 07/11] cli: add --preconfig option Igor Mammedov
2018-05-11 15:36   ` Eric Blake
2018-05-11 17:24   ` [Qemu-devel] [PATCH v8 " Igor Mammedov
2018-05-04  8:37 ` [Qemu-devel] [PATCH v7 08/11] tests: extend qmp test with preconfig checks Igor Mammedov
2018-05-16 18:20   ` Eduardo Habkost
2018-05-16 22:21   ` Eric Blake
2018-05-17 11:28     ` [Qemu-devel] [PATCH v8 " Igor Mammedov
2018-05-17 13:43       ` Eric Blake
2018-05-04  8:37 ` [Qemu-devel] [PATCH v7 09/11] qmp: permit query-hotpluggable-cpus in preconfig state Igor Mammedov
2018-05-16 18:24   ` Eduardo Habkost
2018-05-04  8:37 ` [Qemu-devel] [PATCH v7 10/11] qmp: add set-numa-node command Igor Mammedov
2018-05-16 18:26   ` Eduardo Habkost
2018-05-04  8:37 ` [Qemu-devel] [PATCH v7 11/11] tests: functional tests for QMP command set-numa-node Igor Mammedov
2018-05-16 18:27   ` Eduardo Habkost
2018-05-16 22:12   ` Eduardo Habkost
2018-05-17  8:01     ` Igor Mammedov
2018-05-17 11:27       ` Igor Mammedov
2018-05-17 11:30   ` [Qemu-devel] [PATCH v8 " Igor Mammedov
2018-05-16 19:02 ` [Qemu-devel] [PATCH v7 00/11] enable numa configuration before machine_init() from QMP Eduardo Habkost
2018-05-24 15:42   ` Markus Armbruster
2018-05-28  9:40     ` Igor Mammedov
2018-05-30 10:47 ` Igor Mammedov
2018-05-30 16:22   ` Eduardo Habkost

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=20180525193934.GN8988@localhost.localdomain \
    --to=ehabkost@redhat.com \
    --cc=armbru@redhat.com \
    --cc=imammedo@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 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).