From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46103) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBjB2-00075o-JP for qemu-devel@nongnu.org; Fri, 07 Feb 2014 06:01:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WBjAr-0003GD-2T for qemu-devel@nongnu.org; Fri, 07 Feb 2014 06:00:56 -0500 Received: from cantor2.suse.de ([195.135.220.15]:54474 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBjAq-0003Fw-OI for qemu-devel@nongnu.org; Fri, 07 Feb 2014 06:00:44 -0500 Message-ID: <52F4BCD8.5020400@suse.de> Date: Fri, 07 Feb 2014 12:00:40 +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> <52F27B5E.2030403@suse.de> <52F27BA9.5070000@redhat.com> <52F27E24.1060104@suse.de> <52F4B84D.9040901@redhat.com> In-Reply-To: <52F4B84D.9040901@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 11:41, schrieb Paolo Bonzini: > Il 05/02/2014 19:08, Andreas F=C3=A4rber ha scritto: >> http://wiki.qemu.org/Features/QOM#TODO >> >> Anthony wants buses to go away completely. So that seems a legacy >> concept to me even though they do not seem to be gone tomorrow. >=20 > The way I read that, buses would be replaced by controller devices. >=20 > This is unrelated to showing the devices according to the bus topology > (which still exists in either approach), which is what "info qtree" > device. I guess if controller devices existed, you'd add interfaces > like BusProvider and BusChildEnumerator, or equivalently some "magic" > properties to do the same, and use that in "info qtree". Actually my point was that in Anthony's model you get devices on their controller device simply by looking at link properties on the foo controller device. No special bus code is required any more! Apart from Anthony or someone having to do the actual conversion at some point, the big unanswered question is how do we share code between PCI bus hosts - for PCI host bridges we can place code in the QOM base type (think realizing PCIBus with Bandan's series (which I have been refining the last few days)), but for PCI-PCI bridges where there's two that's gonna be slightly more difficult sharing-wise. Andreas --=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