From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXJ8K-0004Fy-Eu for qemu-devel@nongnu.org; Wed, 11 Feb 2009 12:44:24 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXJ8H-0004DG-87 for qemu-devel@nongnu.org; Wed, 11 Feb 2009 12:44:23 -0500 Received: from [199.232.76.173] (port=49404 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXJ8H-0004D6-0C for qemu-devel@nongnu.org; Wed, 11 Feb 2009 12:44:21 -0500 Received: from mx2.redhat.com ([66.187.237.31]:48343) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LXJ8G-0005EQ-HI for qemu-devel@nongnu.org; Wed, 11 Feb 2009 12:44:20 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n1BHiJpL001300 for ; Wed, 11 Feb 2009 12:44:19 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n1BHiJ0c025998 for ; Wed, 11 Feb 2009 12:44:19 -0500 Received: from pike.pond.sub.org (vpn-10-78.str.redhat.com [10.32.10.78]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n1BHi6Mw016262 for ; Wed, 11 Feb 2009 12:44:18 -0500 Subject: Re: [Qemu-devel] [RFC] Machine description as data References: <87iqnh6kyv.fsf@pike.pond.sub.org> <18834.64870.951989.714873@mariner.uk.xensource.com> From: Markus Armbruster Date: Wed, 11 Feb 2009 18:43:58 +0100 In-Reply-To: <18834.64870.951989.714873@mariner.uk.xensource.com> (Ian Jackson's message of "Wed\, 11 Feb 2009 16\:31\:34 +0000") Message-ID: <87mycs6f8h.fsf@pike.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Ian Jackson writes: > 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. > > When an emulation of such a device starts up, it will want to bind to > several parents. How will you represent this ? > > Ian. Generalize the tree to a a directed acyclic graph (DAG)? Got that already, in fact, only the non-tree edges are second-class citizens. They are separate from tree edges, and unlike those, they can only be added by the config() methods. Maybe it would be easier and cleaner to make the data structure a DAG from the start, instead of tacking DAG-edges to a tree as if they were some afterthought.