qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Blue Swirl <blauwirbel@gmail.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Machine description as data prototype, take 3 (was: [RFC] Machine description as data)
Date: Thu, 19 Feb 2009 18:40:10 +0200	[thread overview]
Message-ID: <f43fc5580902190840m211bf81qb0d1a2f8fe83f4b8@mail.gmail.com> (raw)
In-Reply-To: <871vtuafdr.fsf@pike.pond.sub.org>

[-- Attachment #1: Type: text/plain, Size: 4467 bytes --]

On 2/19/09, Markus Armbruster <armbru@redhat.com> wrote:
> Third iteration of the prototype.
>
>  What about an early merge?  If your answer to that is "yes, but", what
>  exactly do you want changed?

Not until the device tree discussion is finished and Qemu release is
out. This isn't something we want to rush in. There is still Paul's
development and even Fabrice's original proposal which both have
relative merits.

>  +static int
>  +dt_parse_int(void *dst, const char *src, dt_prop_spec *spec)

dst should be uint64_t *.

>  +{
>  +    char *ep;
>  +    long val;

uint64_t val

>  +
>  +    assert(spec->size == sizeof(int));
>  +    errno = 0;
>  +    val = strtol(src, &ep, 0);

strtoull

>  +    if (*ep || ep == src || errno || (int)val != val)
>  +        return -1;
>  +    *(int *)dst = val;
>  +    return 0;
>  +}
>  +
>  +static int
>  +dt_parse_ram_addr_t(void *dst, const char *src, dt_prop_spec *spec)

ram_addr_t *dst

>  +{
>  +    char *ep;
>  +    unsigned long val;

ram_addr_t val

>  +
>  +    assert(spec->size == sizeof(ram_addr_t));
>  +    errno = 0;
>  +    val = strtoul(src, &ep, 0);

strtoull

>  +typedef struct dt_device_cpus {
>  +    const char *model;
>  +    int num;
>  +} dt_device_cpus;
>  +
>  +static dt_prop_spec dt_cpus_props[] = {
>  +    DT_PROP_SPEC_INIT("model", dt_device_cpus, model, string),
>  +    DT_PROP_SPEC_INIT("num", dt_device_cpus, num, int),
>  +};

There should be one node for each cpu, not "num". Each node is named
after the CPU model, like /SUNW,UltraSPARC-IIi.

>  +static dt_prop_spec dt_memory_props[] = {
>  +    DT_PROP_SPEC_INIT("ram", dt_device_memory, ram_size, ram_addr_t),
>  +};

Memory node should be name "/memory". It has properties "available"
and "reg", in this case we only want "reg". "reg" property consists of
several phys_addr, size pairs.

>  +static dt_prop_spec dt_pc_misc_props[] = {
>  +    DT_PROP_SPEC_INIT("boot-device", dt_device_pc_misc, boot_device,
>  +                      string),
>  +};

This property is quite standard, the correct place is under "/options".

>  +static dt_prop_spec dt_vga_props[] = {
>  +    DT_PROP_SPEC_INIT("model", dt_device_vga, model, string),
>  +    DT_PROP_SPEC_INIT("ram", dt_device_vga, ram_size, ram_addr_t),

Again, there is no "model" property, but the node name specifies the model.

"ram" is not correct, this should be under "reg" property.

>  +static dt_prop_spec dt_nic_props[] = {
>  +    DT_PROP_SPEC_INIT("model", dt_device_nic, nd.model, string),
>  +    DT_PROP_SPEC_INIT("mac", dt_device_nic, nd.macaddr, macaddr),
>  +    DT_PROP_SPEC_INIT("name", dt_device_nic, nd.name, string),
>  +};

"name" is the node name, you can't use it to anything else.

Again, node name should specify the model.

>  +    root = tree_new_kid(NULL, "", NULL);
>  +    leaf = tree_new_kid(root, "cpus", NULL);
>  +    tree_put_propf(leaf, "model", "%s", "qemu32");
>  +    leaf = tree_new_kid(root, "memory", NULL);
>  +    leaf = tree_new_kid(root, "pc-misc", NULL);

Remove pc-misc.

>  +    pci = tree_new_kid(root, "pci", NULL);
>  +    leaf = tree_new_kid(pci, "piix3", NULL);

"piix3" is equal to "pci". In this case, there will not be any "piix3"
node, "pci" takes it's place. Any known PCI devices use either their
class (like "pci" for PCI bridges) or model specific name, like
"ebus".

>  +    node = tree_node_by_name(pci, "piix3");
>  +    for(i = 0; i < MAX_IDE_BUS * MAX_IDE_DEVS; i++) {
>  +        index = drive_get_index(IF_IDE, i / MAX_IDE_DEVS, i % MAX_IDE_DEVS);
>  +        if (index != -1)
>  +            dt_attach_drive(host, index, node, drives_table[index].bdrv);
>  +    }

For the PIIX IDE controller (under "/pci" node) the correct name is "ide".

>  +    /* Floppy */
>  +    node = tree_node_by_name(conf, "/pc-misc");
>  +    for(i = 0; i < MAX_FD; i++) {
>  +        index = drive_get_index(IF_FLOPPY, 0, i);
>  +        if (index != -1)
>  +            dt_attach_drive(host, index, node, drives_table[index].bdrv);
>  +    }

ISA devices should be put either under a special "/isa" node, or if
there is an PCI-to-ISA bridge, "/pci/isa" or whatever the connection
is.

I have a troubling feeling that you have not read the 1275 standard or
looked how real OpenFirmware machines name things. I've attached a
Sparc64 tree as an example, please also read the OF standards at:

http://playground.sun.com/pub/p1275/

I'd still like to thank you for your efforts so far, this is a
workable starting point.

[-- Attachment #2: fire-t200-tree.bz2 --]
[-- Type: application/x-bzip2, Size: 5823 bytes --]

  parent reply	other threads:[~2009-02-19 16:40 UTC|newest]

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-11 15:40 [Qemu-devel] [RFC] Machine description as data Markus Armbruster
2009-02-11 16:31 ` Ian Jackson
2009-02-11 17:43   ` Markus Armbruster
2009-02-11 18:57   ` Hollis Blanchard
2009-02-12  3:50     ` David Gibson
2009-02-11 18:50 ` Hollis Blanchard
2009-02-11 19:34   ` Blue Swirl
2009-02-12  4:01   ` David Gibson
2009-02-12 10:26     ` Markus Armbruster
2009-02-12 12:49       ` Carl-Daniel Hailfinger
2009-02-12 16:46         ` M. Warner Losh
2009-02-12 18:29           ` Markus Armbruster
2009-02-12 23:58             ` Carl-Daniel Hailfinger
2009-02-13 11:19               ` Markus Armbruster
2009-02-13  1:05             ` David Gibson
2009-02-12 23:35           ` Carl-Daniel Hailfinger
2009-02-12 23:58             ` Paul Brook
2009-02-13  0:32               ` Carl-Daniel Hailfinger
2009-02-13  0:47                 ` Jamie Lokier
2009-02-13  1:46                 ` David Gibson
2009-02-13 14:32                 ` Lennart Sorensen
2009-02-13  0:05             ` M. Warner Losh
2009-02-12 17:52       ` Hollis Blanchard
2009-02-12 18:53         ` Markus Armbruster
2009-02-12 19:33           ` Mitch Bradley
2009-02-13  0:59             ` David Gibson
2009-02-13  1:00         ` David Gibson
2009-02-13  0:43       ` David Gibson
2009-02-13  2:11         ` Carl-Daniel Hailfinger
2009-02-13  2:17           ` David Gibson
2009-02-13  2:45             ` DTS syntax and DTC patches (was: Re: [Qemu-devel] [RFC] Machine description as data) Carl-Daniel Hailfinger
2009-02-13  2:51               ` David Gibson
2009-02-13 20:04           ` [Qemu-devel] [RFC] Machine description as data Jon Loeliger
2009-02-13 20:15             ` Carl-Daniel Hailfinger
2009-02-13 20:19               ` Jon Loeliger
2009-02-12 10:26   ` Markus Armbruster
2009-02-12 12:36     ` Carl-Daniel Hailfinger
2009-02-12 16:07     ` Paul Brook
2009-02-12 17:17       ` Blue Swirl
2009-02-12 18:09       ` Marcelo Tosatti
2009-02-13  0:37     ` David Gibson
2009-02-13 11:26       ` Markus Armbruster
2009-02-13 12:06         ` Paul Brook
2009-02-13 12:48           ` Markus Armbruster
2009-02-13 13:33             ` Paul Brook
2009-02-13 14:13               ` Markus Armbruster
2009-02-13 14:25                 ` Paul Brook
2009-02-13 15:47                   ` Jamie Lokier
2009-02-13 18:36                 ` Mitch Bradley
2009-02-13 19:49                   ` Markus Armbruster
2009-02-13 19:51                     ` Mitch Bradley
2009-02-16  3:42         ` David Gibson
2009-02-16 16:39           ` Markus Armbruster
2009-02-17  3:29             ` David Gibson
2009-02-17  7:54               ` Markus Armbruster
2009-02-17 17:44               ` Paul Brook
2009-02-18  8:36                 ` Markus Armbruster
2009-02-11 19:01 ` Anthony Liguori
2009-02-11 19:36   ` Blue Swirl
2009-02-11 19:56     ` Anthony Liguori
2009-02-12 10:25       ` Markus Armbruster
2009-02-16 16:22 ` [Qemu-devel] Machine description as data prototype, take 2 (was: [RFC] Machine description as data) Markus Armbruster
2009-02-17 17:32   ` Paul Brook
2009-02-18  8:42     ` [Qemu-devel] Machine description as data prototype, take 2 Markus Armbruster
2009-02-19 10:29 ` [Qemu-devel] Machine description as data prototype, take 3 (was: [RFC] Machine description as data) Markus Armbruster
2009-02-19 13:53   ` Paul Brook
2009-02-19 14:55     ` [Qemu-devel] Machine description as data prototype, take 3 Markus Armbruster
2009-02-19 15:03       ` Paul Brook
2009-02-19 14:36   ` Anthony Liguori
2009-02-19 15:00     ` Markus Armbruster
2009-02-19 14:49   ` Anthony Liguori
2009-02-23 17:38     ` Markus Armbruster
2009-02-23 18:58       ` Anthony Liguori
2009-02-24  9:08         ` Markus Armbruster
2009-02-19 16:40   ` Blue Swirl [this message]
2009-02-19 18:30     ` Markus Armbruster
2009-02-20 18:14       ` Blue Swirl
2009-02-20 18:20         ` Paul Brook
2009-02-23 12:00           ` Markus Armbruster
2009-02-23 12:18         ` Markus Armbruster
2009-02-23 18:00 ` [Qemu-devel] Machine description as data prototype, take 4 (was: [RFC] Machine description as data) Markus Armbruster
2009-02-24 20:06   ` Blue Swirl
2009-02-25 12:13     ` [Qemu-devel] Machine description as data prototype, take 4 Markus Armbruster
2009-02-25 20:11       ` Blue Swirl
2009-03-03 17:46 ` [Qemu-devel] Machine description as data prototype, take 5 (was: [RFC] Machine description as data) Markus Armbruster
2009-03-12 18:43 ` [Qemu-devel] Machine description as data prototype, take 6 " Markus Armbruster
2009-03-17 16:06   ` [Qemu-devel] Machine description as data prototype, take 6 Paul Brook
2009-03-17 17:32     ` Markus Armbruster
2009-03-23 15:50 ` [Qemu-devel] Re: [RFC] Machine description as data Markus Armbruster
2009-03-23 15:53   ` Markus Armbruster
2009-03-31  9:16 ` Markus Armbruster
2009-04-17 16:04 ` Markus Armbruster

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=f43fc5580902190840m211bf81qb0d1a2f8fe83f4b8@mail.gmail.com \
    --to=blauwirbel@gmail.com \
    --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).