From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LcaxO-0005az-42 for qemu-devel@nongnu.org; Thu, 26 Feb 2009 02:46:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LcaxN-0005al-4y for qemu-devel@nongnu.org; Thu, 26 Feb 2009 02:46:57 -0500 Received: from [199.232.76.173] (port=49443 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LcaxM-0005ai-Rt for qemu-devel@nongnu.org; Thu, 26 Feb 2009 02:46:56 -0500 Received: from mx20.gnu.org ([199.232.41.8]:9700) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LcaxM-0003rT-1w for qemu-devel@nongnu.org; Thu, 26 Feb 2009 02:46:56 -0500 Received: from spsmtp02oc.mail2world.com ([74.202.142.148]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LcaxK-00059C-Ia for qemu-devel@nongnu.org; Thu, 26 Feb 2009 02:46:54 -0500 From: =?iso-8859-1?Q?Torbj=F6rn_Andersson?= Date: Thu, 26 Feb 2009 07:49:02 +0100 Message-ID: <004601c997de$50cbd7c0$f2638740$@tt@home.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Language: sv Subject: [Qemu-devel] Machine description, an alternativ using XML 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 Greetings! I, and my collegues, have been using QEMU for some time and we had from = the beginning a need for a more flexible and readable machine definition. Therefore we developed a solution based on XML with a parser using = expat. I will try to exemplify our solution with a "snip" a ARM INTEGRATOR = machine. = = .... = = Firstly, in our solution we call properties attributes. We define relationships between objects using textual references, with a naming convention where a name with ':' signals that the name of the target is relative to the object. We also have a explicit memmap, all the global variables in exec.c are = moved into a specific QEMU class. There could be several parallel memmaps and "multi-homed" devices could be attached to several address-spaces. Our XML files are at QEMU startup parsed by expat and our custom code = and we create an instance of a tree, containing all the information. At the = time the machine is created, a copy of the "template" tree is create and we = start a two-pass traversal of the new tree. We start with creating all the objects, which enables us to replace all obj_ref values with obj_ptr = values (Pointers to real objects). From this point we can continue with initializing all our objects, by updating their attributes with the = values in the machine configuration. I our case, we have found that our "targets" are quite similar, and therefore we support "clusters" to be defined in XML. Clusters are not machines but very much alike, an instance of a cluster cannot be the top = of a tree. All interactions between objects are done through interfaces defined in h-files. The interfaces and attributes are registered in a "CLASS and OBJECT" registry that we have added. An object can ask for an interface = for a specific object and the interface is returned, a struct with function pointers. I will not try to describe the solution more, because I believe that you = now see what we have built. There is a lot more details that are quite nice. = We defined a inheritance scheme that allows to share even more between different machines.=20 Our question is now: are you interested in this solution? I think we can quite swiftly provide a patch-set to QEMU where we show the solution in = the ARM-target domain. I know you are looking at a solution based on FDT. My belief is that the = XML solution is more flexible, but I admit that I know very little about = FDT. Further, I believe that one can create FDTs, from the XML machine definitions, in runtime and pass them to the target-os if required. The strong point with the XML solution is that it is very suitable for modeling embedded systems where lots of GPIOs, interrupts, dma-channels, i2c, spi, i2s/pcm etc. I know that this is will result in a large patch set but I think the FDT = is equally big. Further I believe we can have both schemes in QEMU in = parallel, if necessary. Please take this into consideration. We would be happy to share our = solution with QEMU. /Best Regards Torbj=F6rn Andersson