From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47477) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBjJY-0000hR-92 for qemu-devel@nongnu.org; Fri, 07 Feb 2014 06:09:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WBjJP-0005Kh-9Y for qemu-devel@nongnu.org; Fri, 07 Feb 2014 06:09:44 -0500 Received: from cantor2.suse.de ([195.135.220.15]:54660 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBjJO-0005KN-VR for qemu-devel@nongnu.org; Fri, 07 Feb 2014 06:09:35 -0500 Message-ID: <52F4BEEA.5060606@suse.de> Date: Fri, 07 Feb 2014 12:09:30 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1391621709-15620-1-git-send-email-afaerber@suse.de> <52F2795D.10708@redhat.com> <52F27A1D.2040504@suse.de> <52F27B1C.6010307@redhat.com> <52F27C7A.2040701@suse.de> <52F487AE.4060301@redhat.com> In-Reply-To: <52F487AE.4060301@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] scripts: Add qom-tree script as modern equivalent of info qtree List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, armbru@redhat.com, aliguori@amazon.com, lcapitulino@redhat.com Am 07.02.2014 08:13, schrieb Paolo Bonzini: > Il 05/02/2014 19:01, Andreas F=C3=A4rber ha scritto: >> Am 05.02.2014 18:55, schrieb Paolo Bonzini: >>> Il 05/02/2014 18:51, Andreas F=C3=A4rber 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 qtre= e". >>>>>> 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 b= ug) >>>>>> 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-bas= ed >>>> 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 on= e >> has bothered to fix it. If you or Markus care about it, post a patch. = :) >=20 > 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! >=20 > 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. >=20 > 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 peopl= e > 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. >=20 > Yes, it is a different command. Not arguing about that. >=20 >> Not to mention that it will not work for objects that are not devices. >=20 > Yeah, for the handful of classes that are not in the device hierarchy..= . ;> >=20 > Paolo --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg