All of lore.kernel.org
 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 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.