From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L13xl-0003hl-EG for qemu-devel@nongnu.org; Fri, 14 Nov 2008 14:04:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L13xk-0003hY-RB for qemu-devel@nongnu.org; Fri, 14 Nov 2008 14:04:13 -0500 Received: from [199.232.76.173] (port=34007 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L13xk-0003hV-O2 for qemu-devel@nongnu.org; Fri, 14 Nov 2008 14:04:12 -0500 Received: from yw-out-1718.google.com ([74.125.46.155]:36354) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L13xk-0002x1-6h for qemu-devel@nongnu.org; Fri, 14 Nov 2008 14:04:12 -0500 Received: by yw-out-1718.google.com with SMTP id 6so635376ywa.82 for ; Fri, 14 Nov 2008 11:04:09 -0800 (PST) Message-ID: Date: Fri, 14 Nov 2008 21:04:09 +0200 From: "Blue Swirl" Subject: Re: [Qemu-devel] Machine config files In-Reply-To: <200811140332.14093.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811140332.14093.paul@codesourcery.com> 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 11/14/08, Paul Brook wrote: > It's come up in other contexts recently, so I think it's worth mentioning that > I am currently working on adding a machine config file support to qemu. > > I am focusing on the board setup side of things, rather than the user-level > config side. My goal is to come up with a system that will allow e.g. the > entirety of realview.c and gumstix.c to be eliminated. Currently this is > based this round Flattened Device Trees (as used by ppc-linux). > > I have looked at the bits that Fabrice did a while ago. While that contains > some good ideas (which I will probably steal!) it is approaching the problem > from a somewhat different direction. FTDs are a much better fit for some of > my requirements (e.g. being able to pass the config through to the guest OS). libfdt looks like an excellent choice for both Sparc32 and Sparc64, I think the whole OF tree can be represented with it. The config could be passed using the firmware configuration device.