From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LcQ6E-0000m9-TW for qemu-devel@nongnu.org; Wed, 25 Feb 2009 15:11:23 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LcQ6D-0000kq-KV for qemu-devel@nongnu.org; Wed, 25 Feb 2009 15:11:22 -0500 Received: from [199.232.76.173] (port=34195 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LcQ6D-0000kW-9S for qemu-devel@nongnu.org; Wed, 25 Feb 2009 15:11:21 -0500 Received: from mail-fx0-f175.google.com ([209.85.220.175]:37354) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LcQ6C-0004Ci-Sy for qemu-devel@nongnu.org; Wed, 25 Feb 2009 15:11:21 -0500 Received: by fxm23 with SMTP id 23so151154fxm.34 for ; Wed, 25 Feb 2009 12:11:18 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <873ae267fq.fsf@pike.pond.sub.org> References: <87iqnh6kyv.fsf@pike.pond.sub.org> <87hc2lhw46.fsf@pike.pond.sub.org> <873ae267fq.fsf@pike.pond.sub.org> Date: Wed, 25 Feb 2009 22:11:18 +0200 Message-ID: Subject: Re: [Qemu-devel] Machine description as data prototype, take 4 From: Blue Swirl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 2/25/09, Markus Armbruster wrote: > Blue Swirl writes: > > > On 2/23/09, Markus Armbruster 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.