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 <ehabk...@redhat.com> 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 <afaer...@suse.de> 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. 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, 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. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg)
