From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lcfzk-0005Qh-7C for qemu-devel@nongnu.org; Thu, 26 Feb 2009 08:09:44 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lcfzi-0005QV-4o for qemu-devel@nongnu.org; Thu, 26 Feb 2009 08:09:42 -0500 Received: from [199.232.76.173] (port=57498 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lcfzh-0005QS-Vz for qemu-devel@nongnu.org; Thu, 26 Feb 2009 08:09:42 -0500 Received: from mail2.shareable.org ([80.68.89.115]:52444) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lcfzh-00070n-BW for qemu-devel@nongnu.org; Thu, 26 Feb 2009 08:09:41 -0500 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Lcfzf-0001Tg-Kn for qemu-devel@nongnu.org; Thu, 26 Feb 2009 13:09:39 +0000 Date: Thu, 26 Feb 2009 13:09:39 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] Machine description, an alternativ using XML Message-ID: <20090226130939.GB5053@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 Torbjörn Andersson wrote: > Jamie Lokier Wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > .... > > > > > > > > > > > > > > > > > > > > > > > > > > Why so verbose? > > > > > > > > > > 8192 > > > > > > > > > > > > > > 0xc0010000 > > > > > > We aimed for not putting any aditional burdon on QEMU, by defining concepts > like PIC and MEMMAP. Simply Objects and Classes should exist. Then we added > MACHINES and CLUSTERS as types in the XML files. That doesn't make sense. QEMU needs to know about PICs and MEMMAPs whatever syntax it uses. > > Fwiw, Microsoft Virtual PC uses an XML file to describe the machine > > and it makes sense to me. > > Very readable. But, I dislike the complex DTD, which needs to be maintained > when new machine designs arrive. I believe that Classes and Objects, with > relationships, is enough. That's just a DTD at a different level: hard-coded in the program's parsing of Classes, Objects and Attributes. Presumably you want a generic, simple DTD so that you can use some handy generic XML tools and libraries. But your tools need to know about PICs and MEMMAPs too. By hiding it in Classes and Objects, you force the "real" DTD to be hard-coded into multiple tools at the semantic level, including object-relationship checking (that each PIC has exactly one CPU, for example). In other words, preventing generic XML tools from doing anything useful :-) There's abstraction and there's being verbose with no gain. That's not smart XML, and it's not human friendly either. If you don't want to write a DTD, that's ok just don't write a DTD. > Imagine defining a AMP system, not SMP, in VPC. How can we define AMP > machines in FDT? I'm running targets with two CPUs with separate address > spaces and need to do that in the future too. No idea :-) If FDT can't do it, then it's not suitable. If it can be hacked in but it's very messy, than I think it's barely suitable and we'll all be using a wrapper tool to hide it, which is silly. -- Jamie