Re: [Qemu-devel] [PATCH] scripts: Add qom-tree script as modern equivalent of info qtree

[Paolo Bonzini <pbonzini@redhat.com>]

Il 05/02/2014 19:01, Andreas Färber ha scritto:
> Am 05.02.2014 18:55, schrieb Paolo Bonzini:
>> Il 05/02/2014 18:51, Andreas Färber ha scritto:
>>>>> So, even though I think this script is a very welcome addition, I
>>>> don't
>>>>> think it helps settling the question of what to do with "info qtree".
>>>>> IMO there's no good reason to exclude busless devices from "info
>>>> qtree",
>>>>> and it's a bug (of course less severe than crashing, but still a bug)
>>>>> that the busless nand device doesn't appear there.
>>> Don't you see that that is unfixable? We may be able to replace info
>>> qtree by an info qom-tree, which does the equivalent of this QMP-based
>>> script, but qtree ues a completely different display hierarchy than QOM.
>>
>> Yes, that's why it's useful. :)
>>
>> Busless devices can still be listed, either under their parent or as
>> siblings of the system bus.
>
> info qtree has been inconclusive for - what? - two years now and no one
> has bothered to fix it. If you or Markus care about it, post a patch. :)

Is "inconclusive" the right word?  Or is it just that it works for the 
cases that people care about?  There are exactly two cases of busless 
devices in the tree: NAND after Peter's patch, and CPUs.  Wait, on x86 
CPUs do have a bus!

No matter how much I like QOM (I do), I would rather say that the all 
QOM grand plan has been "inconclusive".  99% in-tree uses of QOM are 
just a glorified qdev, buses and all.  You shouldn't be surprised if 
people still care about the "legacy" qdev tree.

> The code uses qdev/qbus functions to list those devices so I don't see
> an easy way of filtering those devices that qdev/qbus missed and
> printing them using the same walking functions.

Make a hash table, walk sysbus and enter devices that have a bus in the 
hash table. Walk /machine and if a device is not in the hash table 
(doesn't have a bus) add it to a list keyed by the QOM parent.  Then 
walk sysbus again, print each device, and after printing a device also 
print the busless part of the QOM subtree rooted at that device.  A bit 
of a hack perhaps, but I suspect it would work for the cases that people 
care about.

> Therefore my saying that
> we would need to walk the QOM hierarchy instead, which is
> output-incompatible with info qtree and thus a different command.

Yes, it is a different command.  Not arguing about that.

> Not to mention that it will not work for objects that are not devices.

Yeah, for the handful of classes that are not in the device hierarchy... ;>

Paolo