[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Machine description as data
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [RFC] Machine description as data |
Date: |
Thu, 12 Feb 2009 19:29:12 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) |
"M. Warner Losh" <address@hidden> writes:
> <address@hidden>
> <address@hidden>
> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
> Mime-Version: 1.0
> Content-Type: Text/Plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> 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.
As to reading configuration in a binary format: let's not complicate
things more than we need. It's just a decorated tree, folks.
[...]
- Re: [Qemu-devel] [RFC] Machine description as data, (continued)
- Re: [Qemu-devel] [RFC] Machine description as data, Ian Jackson, 2009/02/11
- Re: [Qemu-devel] [RFC] Machine description as data, Hollis Blanchard, 2009/02/11
- Re: [Qemu-devel] [RFC] Machine description as data, Blue Swirl, 2009/02/11
- Re: [Qemu-devel] [RFC] Machine description as data, David Gibson, 2009/02/12
- Re: [Qemu-devel] [RFC] Machine description as data, Markus Armbruster, 2009/02/12
- Re: [Qemu-devel] [RFC] Machine description as data, Carl-Daniel Hailfinger, 2009/02/12
- Re: [Qemu-devel] [RFC] Machine description as data, M. Warner Losh, 2009/02/12
- Re: [Qemu-devel] [RFC] Machine description as data,
Markus Armbruster <=
- Re: [Qemu-devel] [RFC] Machine description as data, Carl-Daniel Hailfinger, 2009/02/12
- Re: [Qemu-devel] [RFC] Machine description as data, Markus Armbruster, 2009/02/13
- Re: [Qemu-devel] [RFC] Machine description as data, David Gibson, 2009/02/12
- Re: [Qemu-devel] [RFC] Machine description as data, Carl-Daniel Hailfinger, 2009/02/12
- Re: [Qemu-devel] [RFC] Machine description as data, Paul Brook, 2009/02/12
- Re: [Qemu-devel] [RFC] Machine description as data, Carl-Daniel Hailfinger, 2009/02/12
- Re: [Qemu-devel] [RFC] Machine description as data, Jamie Lokier, 2009/02/12
- Re: [Qemu-devel] [RFC] Machine description as data, David Gibson, 2009/02/12
- Re: [Qemu-devel] [RFC] Machine description as data, Lennart Sorensen, 2009/02/13
- Re: [Qemu-devel] [RFC] Machine description as data, M. Warner Losh, 2009/02/12