Re: [Qemu-devel] [PATCH] qmp: Add qom-path field to query-cpus command

[Eduardo Habkost]

On Fri, May 08, 2015 at 04:46:42PM +0200, Andreas Färber wrote:
> Am 08.05.2015 um 16:36 schrieb Eduardo Habkost:
> > On Fri, May 08, 2015 at 08:51:45AM -0400, Luiz Capitulino wrote:
> >> On Mon,  4 May 2015 16:09:58 -0300
> >> Eduardo Habkost <address@hidden> wrote:
> >>
> >>> This will allow clients to query additional information directly using
> >>> qom-get on the CPU objects.
> >>
> >> Eduardo, I'm not applying this patch this time because Eric's comments
> >> have to be addressed.
> > 
> > Yes, I will submit a new version later.
> 
> If you just add the "since 2.4",
> 
> Reviewed-by: Andreas Färber <address@hidden>
> 
> As to qom-path vs. qom_path, I think we're using qom-path elsewhere in
> QMP or some of the scripts? I mainly care about the QOM properties being
> consistent, so choose as you see fit here.

qapi-code-gen.txt recommends hyphens, but also notes that consistency is
preferred when extending existing commands that already use underscores.
So unless there are objections, the next version of this patch will use
"qom_path".

> 
> As for the reference to /machine/cpus/... I still think you're missing
> the point I made on the call and in my RFC. You shouldn't expect all
> CPUs to live in the same place like they do for PC or pSeries. Instead,

Which point, on which call?

Note that I am not proposing changing where the CPUs live, I was just
adding links in a well-known place, to make things like query-cpus
unnecessary. Machines are still free to place CPUs wherever they want.

> Instead,
> I think exposing the same search-by-type functionality we have in the
> QOM C API in some QMP command (qom-search? qom-find? or qom-list?) will
> be much better than trying to "equalize" the composition tree for the
> benefit of libvirt accessing it by fixed paths. Therefore my abstract
> socket type, and I would propose to do the same thing for the core.

A search-by-type functionality may work, too, but when would it be
available?

Fortunately the qom-path field will be enough for what libvirt needs
today, so it won't need to wait until a new core QOM feature is
implemented to get its work done. If you reject /machine/cpus, I won't
spend time implementing an alternative mechanism.

-- 
Eduardo