[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Machine description as data prototype, take 4
From: |
Blue Swirl |
Subject: |
Re: [Qemu-devel] Machine description as data prototype, take 4 |
Date: |
Wed, 25 Feb 2009 22:11:18 +0200 |
On 2/25/09, Markus Armbruster <address@hidden> wrote:
> Blue Swirl <address@hidden> writes:
>
> > On 2/23/09, Markus Armbruster <address@hidden> 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.
- Re: [Qemu-devel] Machine description as data prototype, take 3, (continued)
- Re: [Qemu-devel] Machine description as data prototype, take 3 (was: [RFC] Machine description as data), Blue Swirl, 2009/02/19
- Re: [Qemu-devel] Machine description as data prototype, take 3, Markus Armbruster, 2009/02/19
- Re: [Qemu-devel] Machine description as data prototype, take 3, Blue Swirl, 2009/02/20
- Re: [Qemu-devel] Machine description as data prototype, take 3, Paul Brook, 2009/02/20
- Re: [Qemu-devel] Machine description as data prototype, take 3, Markus Armbruster, 2009/02/23
- Re: [Qemu-devel] Machine description as data prototype, take 3, Markus Armbruster, 2009/02/23
[Qemu-devel] Machine description as data prototype, take 4 (was: [RFC] Machine description as data), Markus Armbruster, 2009/02/23