From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MF7Ev-0005BC-Ba for qemu-devel@nongnu.org; Fri, 12 Jun 2009 09:56:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MF7Eq-000599-Tr for qemu-devel@nongnu.org; Fri, 12 Jun 2009 09:56:17 -0400 Received: from [199.232.76.173] (port=47648 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MF7Eq-000593-Jm for qemu-devel@nongnu.org; Fri, 12 Jun 2009 09:56:12 -0400 Received: from mx2.redhat.com ([66.187.237.31]:48447) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MF7Ep-0008PH-8n for qemu-devel@nongnu.org; Fri, 12 Jun 2009 09:56:12 -0400 Subject: Re: [Qemu-devel] [PATCH 3/4] Stellaris machine config References: <20090610173803.4674.82538.stgit@wren.home> <20090610173829.4674.2315.stgit@wren.home> <20090611163217.GA12367@shareable.org> From: Markus Armbruster Date: Fri, 12 Jun 2009 15:53:59 +0200 In-Reply-To: <20090611163217.GA12367@shareable.org> (Jamie Lokier's message of "Thu\, 11 Jun 2009 17\:32\:17 +0100") Message-ID: <87r5xp1rt4.fsf@pike.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: qemu-devel@nongnu.org, M P , Paul Brook Jamie Lokier writes: > M P wrote: >> So now, with qdev, it's all official, /every value, constant, and >> bitfield/ is hard coded, in hex, into a different non-code file, with >> no way of derivating or overloading from. > [...] >> In fact, >> the stellaris share /a lot/ between themselves, and there is not a >> single shared line between your two stellaris boards definition file. > > This is a good point. > > I guess FDT is missing a "#include" equivalent, and possibly name > constants. > > That isn't surprising given FDT's original use, to pass an entire > machine description to a running kernel. > > But for QEMU, some way to give names to, say, a standard SoC or a > basic board, or a PC without peripherals, and then refer to them in > another FDT tree, would be useful. > > Whether it's done in QEMU itself or by preprocessing doesn't matter. > Preprocessing would have the advantage that it would output FDTs that > could, maybe, be passed to the guest kernel and just work. Or maybe > QEMU can have a tree preprocessor built in. > > -- Jamie The need for an FDT to pass to the kernel doesn't dictate that we must use it as configuration file. FDT could be generated from the internal machine description.