From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LcIdb-0003En-On for qemu-devel@nongnu.org; Wed, 25 Feb 2009 07:13:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LcIda-0003EU-4e for qemu-devel@nongnu.org; Wed, 25 Feb 2009 07:13:19 -0500 Received: from [199.232.76.173] (port=47879 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LcIdZ-0003ER-W9 for qemu-devel@nongnu.org; Wed, 25 Feb 2009 07:13:18 -0500 Received: from mx2.redhat.com ([66.187.237.31]:36329) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LcIdZ-0003F2-ES for qemu-devel@nongnu.org; Wed, 25 Feb 2009 07:13:17 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n1PCDG4b023180 for ; Wed, 25 Feb 2009 07:13:16 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n1PCDGdh007888 for ; Wed, 25 Feb 2009 07:13:16 -0500 Received: from pike.pond.sub.org (vpn-10-38.str.redhat.com [10.32.10.38]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n1PCDFuj003452 for ; Wed, 25 Feb 2009 07:13:16 -0500 Subject: Re: [Qemu-devel] Machine description as data prototype, take 4 References: <87iqnh6kyv.fsf@pike.pond.sub.org> <87hc2lhw46.fsf@pike.pond.sub.org> From: Markus Armbruster Date: Wed, 25 Feb 2009 13:13:13 +0100 In-Reply-To: (Blue Swirl's message of "Tue\, 24 Feb 2009 22\:06\:08 +0200") Message-ID: <873ae267fq.fsf@pike.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 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.