From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXKGy-0005hW-PI for qemu-devel@nongnu.org; Wed, 11 Feb 2009 13:57:24 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXKGx-0005hG-2u for qemu-devel@nongnu.org; Wed, 11 Feb 2009 13:57:24 -0500 Received: from [199.232.76.173] (port=43311 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXKGw-0005hD-UT for qemu-devel@nongnu.org; Wed, 11 Feb 2009 13:57:23 -0500 Received: from e2.ny.us.ibm.com ([32.97.182.142]:37398) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LXKGw-0007Uj-G4 for qemu-devel@nongnu.org; Wed, 11 Feb 2009 13:57:22 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n1BItLwa001408 for ; Wed, 11 Feb 2009 13:55:21 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n1BIvLuB184312 for ; Wed, 11 Feb 2009 13:57:21 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n1BIvKhL009076 for ; Wed, 11 Feb 2009 13:57:20 -0500 Subject: Re: [Qemu-devel] [RFC] Machine description as data From: Hollis Blanchard In-Reply-To: <18834.64870.951989.714873@mariner.uk.xensource.com> References: <87iqnh6kyv.fsf@pike.pond.sub.org> <18834.64870.951989.714873@mariner.uk.xensource.com> Content-Type: text/plain Date: Wed, 11 Feb 2009 12:57:19 -0600 Message-Id: <1234378639.28751.85.camel@slate.austin.ibm.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: devicetree-discuss On Wed, 2009-02-11 at 16:31 +0000, Ian Jackson wrote: > Markus Armbruster writes ("[Qemu-devel] [RFC] Machine description as data"): > > [stuff] > > Yes, this is a good approach. I have one question though: > > > Define an internal machine configuration data structure. Needs to be > > sufficiently generic to be able to support even oddball machine > > types. Make it a decorated tree, i.e. a tree of named nodes with > > named properties. > > Many real systems are not strictly tree-structured, because there are > hardware devices which connect via several different paths. For > example, much hardware supported by OpenWRT comes with a built-in > bridge chip connected internally to a hidden ethernet card; a tape > library would have one interface for the robot and a bunch of SCSI > tapereaders; etc. I'm not sure these are great examples, since there still a clear hierarchy here (e.g. the ethernet card is "behind" the bridge chip). Also, there is already established practice for representing SoC devices (found in many embedded PowerPC processors): see arch/powerpc/boot/dts. However, what *is* a good example would be the interrupt hierarchy, which can be totally separate from the address/data hierarchy. The device tree is about *devices*, not interfaces. Each node (device) can mark itself as implementing multiple interfaces, which is what the "compatible" property is about. > When an emulation of such a device starts up, it will want to bind to > several parents. How will you represent this ? There is established design for representing the interrupt hierarchy in IEEE1275, using explicit "interrupt-parent" properties to create the interrupt tree. -- Hollis Blanchard IBM Linux Technology Center