From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LY4Gu-0004vd-V3 for qemu-devel@nongnu.org; Fri, 13 Feb 2009 15:04:24 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LY4Gr-0004pN-OE for qemu-devel@nongnu.org; Fri, 13 Feb 2009 15:04:22 -0500 Received: from [199.232.76.173] (port=36793 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LY4Gr-0004p5-GF for qemu-devel@nongnu.org; Fri, 13 Feb 2009 15:04:21 -0500 Received: from az33egw02.freescale.net ([192.88.158.103]:53960) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LY4Gq-0008BI-Qn for qemu-devel@nongnu.org; Fri, 13 Feb 2009 15:04:21 -0500 Subject: Re: [Qemu-devel] [RFC] Machine description as data From: Jon Loeliger In-Reply-To: <4994D6C8.5050004@gmx.net> References: <87iqnh6kyv.fsf@pike.pond.sub.org> <1234378228.28751.79.camel@slate.austin.ibm.com> <20090212040138.GD31142@yookeroo.seuss> <87iqng0x3t.fsf@pike.pond.sub.org> <20090213004305.GB8104@yookeroo.seuss> <4994D6C8.5050004@gmx.net> Content-Type: text/plain Date: Fri, 13 Feb 2009 14:04:12 -0600 Message-Id: <1234555452.2323.5.camel@ld0161-tx32> Mime-Version: 1.0 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: Carl-Daniel Hailfinger Cc: devicetree-discuss , Markus Armbruster , Hollis Blanchard , qemu-devel@nongnu.org On Fri, 2009-02-13 at 03:11 +0100, Carl-Daniel Hailfinger wrote: > On 13.02.2009 01:43, David Gibson wrote: > > On Thu, Feb 12, 2009 at 11:26:46AM +0100, Markus Armbruster wrote: > > > >> I didn't mean to say they are a bad idea for FDTs, just that they're on > >> an awkward level of abstraction for QEMU configuration. There, I'd > >> rather express a PCI address as "02:01.0" than as <0x00000220>. > >> Translating text to binary is the machine's job, not the user's. > >> > > > > Ah, I see what you mean. Hrm, there are several possibilities here, > > we'll have to see which works out best for your purposes. > > > > Using the DTC version included in the coreboot v3 sources would solve > that problem and give you a readable PCI address representation. As would the proposed language enhancements I suggested. jdl