qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Machine description, an alternativ using XML


From: Jamie Lokier
Subject: Re: [Qemu-devel] Machine description, an alternativ using XML
Date: Thu, 26 Feb 2009 13:09:39 +0000
User-agent: Mutt/1.5.13 (2006-08-11)

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 via email to

[Prev in Thread] Current Thread [Next in Thread]