On Fri, May 16, 2014 at 04:52:21PM +0200, Igor Mammedov wrote: > On Thu, 15 May 2014 11:03:49 -0300 > Eduardo Habkost <ehabkost@xxxxxxxxxx> wrote: > > On Thu, May 15, 2014 at 03:48:16PM +0200, Igor Mammedov wrote: [...] > > > > > > Can't we add query-cpus QMP command or something like this to hide path > > > from user. > > > > That would work, too. But why is a dedicated "query-cpus" command better > > than something like "qom-list path=/machine/cpus" (that could simply > > return a list of links to the actual CPU objects)? > So that not to stall the work on deciding on > - if exposing not yet stables QOM paths as stable ABI is a good thing, I > recall Andreas objecting to using QOM paths with device hotplug This surprises me. > - what paths to CPUs should be wrt stalled topology discussion > I don't see why it depends on the topology discussion: if we are capable of keeping "query-cpus" working after we introduce the topology hierarchy, I believe we are perfectly capable of keeping symlinks on "/machine/cpus" working, too. Even if we change the actual paths later and introduce a more complex QOM hierarchy somewhere else. Isn't the reuse of infrastructure for list/get/set operations the whole point of QOM? -- Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list