On Wed, May 07, 2014 at 05:39:36PM +0200, Andreas Färber wrote: > Hi Hani, > > Am 27.04.2014 12:29, schrieb Hani Benhabiles: > > Signed-off-by: Hani Benhabiles <h...@linux.com> > > --- > > > > Not sure whether the qobject stringifying functions could fit or be of some > > use > > elsewhere. Thus, I kept them as static near the only place where they are > > used > > at the moment. > > Your "info qom-tree" reads quite similar to my proposed qom-tree script: > http://patchwork.ozlabs.org/patch/317224/ > > For HMP I had been working on a command "info qom-composition" that > emits a trimmed-down overview-style output, such as for x86_64: > > (qemu) info qom-composition > /machine (pc-i440fx-2.1-machine) > /peripheral-anon (container) > /peripheral (container) > /unattached (container) > /sysbus (System) > /device[0] (qemu64-x86_64-cpu) > /apic (apic) > /device[1] (kvmvapic) > /device[2] (i440FX) > /device[3] (PIIX3) > /isa.0 (ISA) > /device[4] (isa-i8259) > /device[5] (isa-i8259) > /device[6] (cirrus-vga) > /device[7] (hpet) > /device[8] (mc146818rtc) > /device[9] (isa-pit) > /device[10] (isa-pcspk) > /device[11] (isa-serial) > /device[12] (isa-parallel) > /device[13] (i8042) > /device[14] (vmport) > /device[15] (vmmouse) > /device[16] (port92) > /device[17] (isa-fdc) > /device[18] (e1000) > /device[19] (piix3-ide) > /ide.0 (IDE) > /ide.1 (IDE) > /device[20] (ide-cd) > /device[21] (PIIX4_PM) > /i2c (i2c-bus) > /device[22] (smbus-eeprom) > /device[23] (smbus-eeprom) > /device[24] (smbus-eeprom) > /device[25] (smbus-eeprom) > /device[26] (smbus-eeprom) > /device[27] (smbus-eeprom) > /device[28] (smbus-eeprom) > /device[29] (smbus-eeprom) > /icc-bridge (icc-bridge) > /icc (icc-bus) > /fw_cfg (fw_cfg) > /i440fx (i440FX-pcihost) > /pci.0 (PCI) > /ioapic (ioapic) > > I believe both commands can coexist. Question is how. > > My tree-walking implementation is not based on QMP and thus much > slimmer. I didn't have to care about printing properties yet - that I > deferred to a qom-get HMP command (which based on previous feedback we > should implement either way). Possibly we could rebase your patch onto > mine, adding an argument for whether or not to print the properties? >
Sure, I am fine with rebasing the patch on top of yours if that ends up with less duplicated work. > Compared to my script, your "info qom-tree" does not allow to change the > root, so I believe we would need to print from "/" on (rather than > "/machine"), for dumping RNG backends etc. as well. The alternative > would be having arguments to the command, for specifying root and/or > output style. A path argument (defaulting to "/") seems like a good approach to me, but I have no strong preference on this.
