"Dr. David Alan Gilbert" <dgilb...@redhat.com> writes: > * Markus Armbruster (arm...@redhat.com) wrote: >> "Dr. David Alan Gilbert (git)" <dgilb...@redhat.com> writes: >> >> > From: "Dr. David Alan Gilbert" <dgilb...@redhat.com> >> > >> > Allow a bunch of the info commands to be used in preconfig. >> > >> > version, chardev, name, uuid,memdev, iothreads >> > Were enabled in QMP in the previous patch from Igor >> >> Yes, these are okay together with PATCH 4. >> >> > status, hotpluggable_cpus >> > Was enabled in the original allow-preconfig series >> >> query-status looks okay to me. >> >> > history >> > is HMP specific >> >> Yes. >> >> > usbhost, qom-tree, numa >> > Don't have a QMP equivalent >> >> HMP commands without a QMP equivalent are okay if their functionality >> makes no sense in QMP, or is of use only for human users. >> >> Example for "makes no sense in QMP": setting the current CPU, 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. > > Right, but they do already exist; it's possible we may want to fix/add > QMP versions - but this series isn't about going through and fixing > existing stuff up. > >> Now let's review the three commands: >> >> * Gerd, why does "info usbhost" have no QMP equivalent? >> >> * Eduardo, why does "info numa" have no QMP equivalent? >> >> * "info qom-tree" is a recursive variant of qom-list that skips anything >> but children. This convenience command exists so you don't have to >> filter and string together output from many qom-list. >> >> I think it stands to reason that if providing "info qom-tree" makes >> sense, then so does qom-list (HMP and QMP). If qom-list, then >> qom-list-types, qom-list-properties, qom-get, and probably even >> qom-set (I've always been suspicious of qom-set, but that has nothing >> to do with preconfig state). >> >> It might make sense to split off the whole QOM shebang into a separate >> patch. > > People have been trying to add qom-get etc for quite a while (I tried a > couple of years ago); it gets stuck in type display issues. I've not > directly seen a need for those other variants, but qom-get is something > I'd love to have, still that's a job for another patch.
Yes. > 'info qom-tree' is very very useful when debugging qemu to see what the > basic state we're building is; it's primarily for debugging. I'm not at all opposed to enabling qom-tree, but I want its QMP building blocks enabled as well then. I think enabling their HMP buddies as well would only make sense.