qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Machine description, an alternativ using XML
Date: Thu, 26 Feb 2009 13:09:39 +0000	[thread overview]
Message-ID: <20090226130939.GB5053@shareable.org> (raw)

Torbjörn Andersson wrote:
> Jamie Lokier Wrote:
> > > <MACHINE name=ARM-INTEGRATOR>
> > >   <OBJECT name="cpu" class="ARM926ej">
> > >     <ATTRIBUTE name="mhz">	<value integer="208"/>  </ATTRIBUTE>
> > >     <ATTRIBUTE name="dtcm_size">	<value integer="8192"/>
> > </ATTRIBUTE>
> > > 	<snipp...>
> > >     <ATTRIBUTE name="memmap">	<value obj_ref=":memmap"/>
> > </ATTRIBUTE>
> > >   </OBJECT>
> > >   <OBJECT name="memmap" class="MEMMAP">
> > >   </OBJECT>
> > >     ....
> > >   <OBJECT name="pic" class="pl190">
> > >     <ATTRIBUTE name="pic">	<value obj_ref=":cpu"/>  </ATTRIBUTE>
> > >     <ATTRIBUTE name="memmap">	<value obj_ref=":memmap"/>
> > </ATTRIBUTE>
> > >     <ATTRIBUTE name="base">	<value integer="0xc0010000"/>
> > </ATTRIBUTE>
> > >   </OBJECT>
> > > <MACHINE/>
> > 
> > Why so verbose?
> > 
> > <machine name="arm-integrator">
> >   <cpu name="cpu0" type="ARM926ej">
> >      <clock mhz="208"/>
> >      <dtcm_size>8192</dtcm_size>
> >      <memmap ref="memmap0"/>
> >   </cpu>
> >   <memmap name="memmap0"/>
> >   <pic name="pic" type="pl190">
> >      <memmap ref="memmap0"/>
> >      <cpu ref="cpu0"/>
> >      <base>0xc0010000</base>
> >   </pic>
> > </machine>
> 
> 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

             reply	other threads:[~2009-02-26 13:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-26 13:09 Jamie Lokier [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-02-26  9:36 [Qemu-devel] Machine description, an alternativ using XML Jamie Lokier
2009-02-26 12:01 ` Torbjörn Andersson
2009-02-26 13:24   ` Steve Fosdick
2009-02-26 18:48     ` Andreas Färber
2009-02-26 21:47       ` Jamie Lokier
2009-02-26 19:41 ` Blue Swirl
2009-02-26  6:49 Torbjörn Andersson
2009-02-26 16:06 ` Paul Brook
2009-02-26 22:14   ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090226130939.GB5053@shareable.org \
    --to=jamie@shareable.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).