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

["Andreas Färber" <afaerber@suse.de>]

Am 07.02.2014 08:13, schrieb 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.

I am not offended about people caring about legacy devices. I am
offended that people are trying to revert good QOM changes so that they
match their expectations from legacy concepts. I have stated at two KVM
Forums already that qdev is dead. What else do I have to do? Rename
qdev.c to device.c? That's pretty easy to do if it solves these qdev
discussions...

>> 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.

Don't instruct *me*, post a patch. It does sound like a hack to me. Not
even SysBusDevices are shown in the proper composition in info qtree.

What I have been drafting is an info qom-composition command, which may
show you have the composition differs if you're unwilling to use
qom-list or qom-tree to see for yourself. We could still highlight buses
in that model, if desired. But I'd rather decouple it from random
properties in the new command.

Andreas

>> 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


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg