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