On Fri, 8 Jun 2018 09:18:46 +0100 "Dr. David Alan Gilbert" <dgilb...@redhat.com> wrote:
> * 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. I'd prefer #3 if we going to expose HMP at all or #1. #3 would allow testing via HMP for those who can't use qmp-shell. we can trim HMP list to allowed-preconfig commands or audit respective QMP variants (they should work without changes) and flag them with allowed-preconfig. > > Dave > > -- > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK >
