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

[Paolo Bonzini]

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