Re: [Qemu-devel] [PATCH 4/6] hmp: Add info commands for preconfig

[Markus Armbruster]

"Dr. David Alan Gilbert" <address@hidden> writes:

> * Markus Armbruster (address@hidden) wrote:
>> "Dr. David Alan Gilbert" <address@hidden> writes:
>> 
>> > * Markus Armbruster (address@hidden) wrote:
>> >> "Dr. David Alan Gilbert" <address@hidden> writes:
>> >> 
>> >> > * Markus Armbruster (address@hidden) wrote:
>> >> >> Peter Xu <address@hidden> writes:
>> >> >> 
>> >> >> > On Tue, Jun 05, 2018 at 01:26:34PM +0100, Dr. David Alan Gilbert 
>> >> >> > (git) wrote:
>> >> >> >> From: "Dr. David Alan Gilbert" <address@hidden>
>> >> >> >> 
>> >> >> >> Allow a bunch of the info commands to be used in preconfig.
>> >> >> >> Could probably add most of them.
>> >> >> >
>> >> >> > I guess some of them may not work yet during preconfig.  E.g.:
>> >> >> >
>> >> >> > $ ./x86_64-softmmu/qemu-system-x86_64 -preconfig -monitor stdio
>> >> >> > QEMU 2.12.50 monitor - type 'help' for more information
>> >> >> > (qemu) info mtree
>> >> >> > address-space: memory
>> >> >> >   0000000000000000-ffffffffffffffff (prio 0, i/o): system
>> >> >> >
>> >> >> > address-space: I/O
>> >> >> >   0000000000000000-000000000000ffff (prio 0, i/o): io
>> >> >> >
>> >> >> > But it's fine to enable that I guess.
>> >> >> >
>> >> >> > (Which "info" command would you want to use during preconfig?)
>> >> >> >
>> >> >> >> 
>> >> >> >> Signed-off-by: Dr. David Alan Gilbert <address@hidden>
>> >> >> >
>> >> >> > Reviewed-by: Peter Xu <address@hidden>
>> >> >> 
>> >> >> The reason for having -preconfig is us despairing of making -S do the
>> >> >> right thing.  We'd have to *understand* the tangled mess that is our
>> >> >> startup, and rearrange it so QMP becomes available early enough for
>> >> >> configuring NUMA (and other things), yet late enough for everything to
>> >> >> work.
>> >> >> 
>> >> >> -preconfig is a cheap hack to avoid this headache, by bypassing almost
>> >> >> all of "everything".
>> >> >> 
>> >> >> Now you bring back some of "everything".  Dangerous.  You better show 
>> >> >> it
>> >> >> actually works.  Until you do:
>> >> >> 
>> >> >> NAK
>> >> >
>> >> > Well I did test each command in here to make sure it didn't
>> >> > crash/produce complete junk; but here's the output with the v2 of this
>> >> > patch that Igor R-b:
>> >> [...]
>> >> 
>> >> For the sake of the argument, let's assume these commands all work in
>> >> preconfig state.  Are their QMP equivalents all available in preconfig
>> >> state?
>> >
>> > That I don't know; I was happy to fix my list to the ones
>> > Igor recommended.  If you object to some particular entries I'll
>> > be happy to change them.
>> 
>> HMP must not provide more functionality than QMP.  Specifically, we may
>> provide "info FOO" only when we also provide query-FOO.
>>
>> There are exceptions to this rule.  I don't think they apply here.  I'm
>> prepared to discuss them, of course.
>
> No, that's strictly not true;  HMP can provide anything that helps
> a human debug stuff.

Yes, but...

>                       The requirement is that if a tool needs it then it
> must be provided in QMP.

... it must not do that at the expense of QMP's completeness.
Permitting that would be a break from how we worked since QMP became
supported in 0.14 or so.  Seven years, time flies.

The hard requirement for QMP from day one was "provide everything
machine clients need".  To avoid speculation and endless arguments about
what might be needed / not needed, we resolved to approximate this by
"provide everything, except stuff that's *clearly* of no use to
machines".  This has been spelled out on this list several times.
Here are two relatively recent iterations:

Message-ID: <address@hidden>
https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05309.html

Message-ID: <address@hidden>
https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg00247.html

Quoting the latter:

In general, functionality available in HMP should also available in QMP.
Exceptions include functionality that makes no sense in QMP, or is of
use only for human users.  If you think your command is an exception,
please explain why in the commit message.

If it isn't, you need to implement it for QMP (including suitable test
cases), then rewrite the HMP version to reuse either the QMP command or
a common core.

Example for "makes no sense in QMP": setting the current CPU[1], because
a QMP monitor doesn't have a current CPU.

Examples for "is of use only for human users": HMP command "help", the
integrated pocket calculator[2].

End quote.

But we're not even arguing about a new HMP command, we're arguing about
making existing commands available in preconfig state.  I assume that if
an HMP command is useful in preconfig state, then its QMP buddy is also
useful there.  I therefore asked you whether their QMP equivalents are
all available in preconfig state.  The answer I expected was a short
table of three columns: HMP command you propose to enable, QMP buddy if
any, whether the QMP buddy is available in preconfig state yes/no.
Estimated effort: minutes.  What I got instead of this data was an
argument about fundamental design decisions.  Fine, reexaminating
fundamentals once in a while isn't a bad idea.  But may I have my data
now?

[...]