Re: [Qemu-devel] [PATCH v3 5/7] hmp: Add info commands for preconfig

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Markus Armbruster (armbru@redhat.com) wrote:
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
> 
> > * Markus Armbruster (armbru@redhat.com) wrote:
> >> "Dr. David Alan Gilbert (git)" <dgilbert@redhat.com> writes:
> >> 
> >> > From: "Dr. David Alan Gilbert" <dgilbert@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.

Hmm; OK, enabling qom-list, qom-get, qom-set, qom-list-types,
qom-list-properties for qmp.
qom-list and qom-set enabled in HMP.

Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK