* Markus Armbruster (arm...@redhat.com) wrote: > "Dr. David Alan Gilbert" <dgilb...@redhat.com> writes: > > > * Markus Armbruster (arm...@redhat.com) wrote: > >> "Dr. David Alan Gilbert" <dgilb...@redhat.com> writes: > >> > >> > * Markus Armbruster (arm...@redhat.com) wrote: > >> >> "Dr. David Alan Gilbert" <dgilb...@redhat.com> writes: > >> >> > >> >> > * Markus Armbruster (arm...@redhat.com) wrote: > >> >> >> Peter Xu <pet...@redhat.com> writes: > >> >> >> > >> >> >> > On Tue, Jun 05, 2018 at 01:26:34PM +0100, Dr. David Alan Gilbert > >> >> >> > (git) wrote: > >> >> >> >> From: "Dr. David Alan Gilbert" <dgilb...@redhat.com> > >> >> >> >> > >> >> >> >> 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 <dgilb...@redhat.com> > >> >> >> > > >> >> >> > Reviewed-by: Peter Xu <pet...@redhat.com> > >> >> >> > >> >> >> 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: <8737cngvq6....@dusky.pond.sub.org> > https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05309.html > > Message-ID: <8760hrxtcn....@dusky.pond.sub.org> > 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?
I believe that table is in the v3 version patch 5. Dave > [...] -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK