qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] Machine description as data


From: Carl-Daniel Hailfinger
Subject: Re: [Qemu-devel] [RFC] Machine description as data
Date: Fri, 13 Feb 2009 00:58:46 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.17) Gecko/20080922 SUSE/1.1.12-0.1 SeaMonkey/1.1.12

On 12.02.2009 19:29, Markus Armbruster wrote:
> "M. Warner Losh" <address@hidden> writes:
>
>   
>> In message: <address@hidden>
>> Carl-Daniel Hailfinger <address@hidden> writes:
>> : > I didn't mean to say they are a bad idea for FDTs, just that they're on
>> : > an awkward level of abstraction for QEMU configuration.  There, I'd
>> : > rather express a PCI address as "02:01.0" than as <0x00000220>.
>> : > Translating text to binary is the machine's job, not the user's.
>> : 
>> : Coreboot v3 is using some device tree variant which is IMHO a bit more
>> : user friendly. The tree below is incomplete (for example, it leaves out
>> : the PCI bus number and assumes that it is zero by default), but you
>> : surely get the idea.
>> : 
>> : /{
>> :     mainboard_vendor = "Gigabyte";
>> :     mainboard_name = "M57SLI";
>> :     cpus { };
>> :     address@hidden {
>> :     };
>> :     address@hidden {
>> :         address@hidden,0 { /* MCP55 RAM? */ 
>> :         };
>> :         address@hidden,0 {
>> :             /config/("southbridge/nvidia/mcp55/lpc.dts");
>> :             address@hidden {
>>
>> <etc>
>>
>> I'd like to make a couple of comments here.
>>
>> One, I dislike the DTS syntax.  It is hard to learn to read, and I
>> always have to have the manual in my hands to read it.
>>
>> However, every board that's being produced for powerpc has the DTB at
>> least available.  It has to be, or (recent?) Linux kernels flat out
>> won't work.  This suggests that it might be a good idea to look at
>> this format.
>>
>> There's DTS and DTB.  One is the source, the other is the binary
>> created from the source.  I'd recommend that qemu actually use the DTB
>> rather than the DTS to implement things.  This way one could have a
>> nicer syntax like the above and generate the DTB, or one could use the
>> DTS provided by a vendor if there was a more specific board they
>> wanted qemu to emulate.
>>     
>
> As far as I know, dtc can decompile DTB into DTS.
>
> I'm not a fan of DTS syntax either, but if we choose FDT, then inventing
> an alternative syntax seems rather pointless to me.
>   

If the alternative syntax is more readable, why not?

If the DTS text file is compiled into DTB anyway, there's absolutely no
reason to make the text file hard to read for humans. Except maybe
making sure that nobody will ever want to change them, and in that case
we can advise developers to modify the DTB directly.

Compilers for DTS variants do exist. For example, coreboot v3 has one.

> As to reading configuration in a binary format: let's not complicate
> things more than we need.  It's just a decorated tree, folks.
>   

How exactly do you represent a digraph with some cycles as a decorated
tree? The solution should allow people without an extensive background
in IEEE1275 to change the graph as needed.
Having to keep a calculator handy for PCI bus addresses is embarrassing
(and with a calculator, requiring the user to determine the full CF8/CFC
PCI config cycles is not that much more effort ;-) ).


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/





reply via email to

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