* 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. The requirement is that if a tool needs it then it must be provided in QMP. > I wish there was a way to automate "provide command in HMP when its > buddy is available in QMP", but since the buddies are only connected by > code, that seems infeasible. > > Without such automation, the two sets of available commands need to be > kept consistent manually. The larger they are, the more of a bother. > > Bother is fine when it provides commensurate value to users. Options in > increasing order of value provided: > > (1) HMP becomes ready only after we exit preconfig state (what I > proposed in Message-ID: <87603cxob9....@dusky.pond.sub.org>. > > (2) HMP provides help, quit, exit-preconfig. > > (3) HMP provides (a subset of) the commands QMP provides. > > I figure the maintenance cost of (1) and (2) will be negligible, but (3) > could be a drag. Are you sure it's worthwhile? I'm not prepared to restrict to (2), and I'm not prepared to restrict HMP to a subset of QMP; As I said previously, if there's a command that you think is incorrect/broken that I've enabled then I'm happy to remove it. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK