From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lcmo8-0007DT-OU for qemu-devel@nongnu.org; Thu, 26 Feb 2009 15:26:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lcmo7-0007D7-Dk for qemu-devel@nongnu.org; Thu, 26 Feb 2009 15:26:11 -0500 Received: from [199.232.76.173] (port=49654 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lcmo7-0007D2-3a for qemu-devel@nongnu.org; Thu, 26 Feb 2009 15:26:11 -0500 Received: from spsmtp02oc.mail2world.com ([74.202.142.148]:3900) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lcmo6-0000Ms-No for qemu-devel@nongnu.org; Thu, 26 Feb 2009 15:26:10 -0500 From: =?iso-8859-1?Q?Torbj=F6rn_Andersson?= References: <004601c997de$50cbd7c0$f2638740$@tt@home.se> <200902261606.06841.paul@codesourcery.com> In-Reply-To: <200902261606.06841.paul@codesourcery.com> Subject: SV: [Qemu-devel] Machine description, an alternativ using XML Date: Thu, 26 Feb 2009 21:26:08 +0100 Message-ID: <007301c99850$7671e0b0$6355a210$@tt@home.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Language: sv 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 Thanks for your replies. I do not really aim to force my solution into = QEMU, but I try visualize the good parts. It would be a bonus if my code end = up contributed. I recognize that my XML usage is quite poor. I will tight it up = according to Jamie's suggestion. I solved my problem at the time and it have been = good enough since then. We have now been using it with lots of targets, >20. = We have been able to identify the common parts of our machines and = decreased our maintenance code and duplication.=20 Paul B wrote: > It looks like you're just using XML to encapsulate simple > pairs, > which IMHO is completely the wrong way to use XML. I don't see the fundamental difference compared to FDT. Does it mean = that FDT is wrong too? I guess you can explain a bit more. mpic: pic@40000 { interrupt-controller; #address-cells =3D <0>; #interrupt-cells =3D <2>; reg =3D <0x40000 0x40000>; compatible =3D "chrp,open-pic"; device_type =3D "open-pic"; }; Note: if FDT fulfills our requirements, I expect that we will move to = FDT too. All our QEMU knows about is classes, attributes and interfaces. Clusters = and Machines are simply specialized classes. Defining machines/clusters in = our solution is like picking building blocks and sticking them together in = XML. A building block could be a PIC or an entire cluster. There is no "naming-convention" in our XML solution what so ever. The = reason for why we have object reference described as strings like ":pic" are = two. (pic is simply a suitable name for a pl190) First we have a layered design, where a cluster/machine describes one = layer. A cluster in our design could as an example be the OMAP SOC. The OMAP = SOC is alone not a machine. It needs to be complemented with RAM and other = stuff and that defines the machine and hooks it together with known parts in = the OMAP cluster. The OMAP itself could also be defined with other clusters. Therefore the ':' in the object reference tells QEMU where to look. =20 The second reason is that we do not want to use fully qualified names because we might want to run two or more machines within the same QEMU instance. We prefer to have all machines in one QEMU instance because it = is easier to control and deterministic. (I can submit patches for this too, including CPU threading support) In the end we got object names like this _ __ I recommend having named objects because it makes life easier when = debugging the state of the machine. Imagine having several objects of the same = class and only be able to separate them with the address to the state-struct. = We also have a object browser, where we can browse the machine and all its components with current values on attributes, quite powerful and useful = for both users and QEMU developers. I want to mention on more thing about our clusters and machines. In our = XML solution a cluster can be coupled with a specific "builder" class. The standard builder, used when none is specified, simple creates all = objects, resolves all object references (obj_ref -> obj. pointers) and sets all attributes. A specialized "builder" can do more, like adding interfaces = for the entire cluster. I.e. things that are not suitable or impossible to = be defined in XML. Paul wrote: > I think one of the most important goals of qemu machine description > infrastructure is to abstract this kind of detail away from the > devices. Such centralization of logic is well suited in a class with the specific role of easing the "load" of its children. In this case a "builder" = class described above.=20 Andreas F wrote: >True, but XML itself does not allow for arbitrary graphs, only trees. =20 Hmm, what kind of graphs could be needed? (Out of curiosity)=20 Blue S. wrote: > OK, so now we have: > 1 - Fabrice's original proposal > 2 - Paul's FDT based work > 3 - Mark's FDT based work > 4 - Torbj=F6rn's XML based configuration > 5 - Microsoft XML configuration I'm honored to be on the list and not last! :) /BR Torbj=F6rn