Re: [Qemu-devel] Machine description as data prototype, take 4

[Blue Swirl <blauwirbel@gmail.com>]

On 2/25/09, Markus Armbruster <armbru@redhat.com> wrote:
> Blue Swirl <blauwirbel@gmail.com> writes:
>
>  > On 2/23/09, Markus Armbruster <armbru@redhat.com> wrote:
>  >> Fourth iteration of the prototype.  I'm not asking to consider a merge
>  >>  at this time.
>  >
>  >>  +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),
>  >>  +};
>  >
>  > Please use "const".
>
>  Done.
>
>  >>  +static void dt_memrng_rom(dt_device_memrng *rng,
>  >>  +                          target_phys_addr_t phys_addr, ram_addr_t maxsz,
>  >>  +                          const char *dir, const char *image, int top)
>  >>  +{
>  >>  +    char buf[1024];
>  >>  +    int size;
>  >>  +
>  >>  +    snprintf(buf, sizeof(buf), "%s/%s", dir, image);
>  >>  +    size = get_image_size(buf);
>  >>  +    if (size < 0 || size > maxsz)
>  >>  +        goto error;
>  >>  +    if (top)
>  >>  +        phys_addr = phys_addr + maxsz - size;
>  >>  +    dt_memrng(rng, phys_addr, size, qemu_ram_alloc(size), IO_MEM_ROM);
>  >>  +    if (load_image(buf, phys_ram_base + rng->host_offs) != size)
>  >>  +        goto error;
>  >>  +    return;
>  >>  +
>  >>  +error:
>  >>  +    fprintf(stderr, "qemu: could not load image '%s'\n", buf);
>  >>  +    exit(1);
>  >>  +}
>  >
>  > If this is going to be the generic ROM loader, it should also handle
>  > ELF format images. But for the PC this is enough.
>
>  Yes.
>
>  [more const fallout...]
>  >>   void register_machines(void)
>  >>   {
>  >>  +    extern QEMUMachine pcdt_machine;
>  >
>  > Put this into hw/boards.h.
>
>  Done.  A leftover from the early reckless hacking stage.
>
>  >>  +tree *tree_new_kid(tree *parent, const char *name, void *user)
>  >
>  > The OF term for "kid" is "child".
>  >
>  >>  +tree *tree_sibling(const tree *node)
>  >
>  > Here the OF word is "peer".
>
>  Do you mean to recommend renames?  Note that right now this is a
>  perfectly generic decorated tree, which could be used for anything, not
>  just device trees.
>
>  While I'm not particular about "kid" vs. "child", I find "peer" clearly
>  inferior.  "Sibling" is obvious: child of the same parent.  "Peer" could
>  be anything.

Maybe the function usage is different, "peer" gets passed the child
node and it returns a node from the same level, whereas your function
takes the parent node. Or does it?

Anyway, "sibling" is still unnecessary deviation.