On Thu, May 24, 2018 at 08:16:20PM +0200, Markus Armbruster wrote:
> Markus Armbruster <arm...@redhat.com> writes:
>
> > Igor Mammedov <imamm...@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 <imamm...@redhat.com>
> >> Reviewed-by: Eric Blake <ebl...@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" <dgilb...@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.
--
Eduardo
