From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXyAz-0005OR-IP for qemu-devel@nongnu.org; Fri, 13 Feb 2009 08:33:53 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXyAx-0005Mt-BQ for qemu-devel@nongnu.org; Fri, 13 Feb 2009 08:33:52 -0500 Received: from [199.232.76.173] (port=56896 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXyAw-0005Me-On for qemu-devel@nongnu.org; Fri, 13 Feb 2009 08:33:51 -0500 Received: from mx20.gnu.org ([199.232.41.8]:31491) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LXyAw-0003IF-Gg for qemu-devel@nongnu.org; Fri, 13 Feb 2009 08:33:50 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LXyAv-0004sS-EY for qemu-devel@nongnu.org; Fri, 13 Feb 2009 08:33:49 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [RFC] Machine description as data Date: Fri, 13 Feb 2009 13:33:46 +0000 References: <87iqnh6kyv.fsf@pike.pond.sub.org> <200902131206.42427.paul@codesourcery.com> <87ocx6pkol.fsf@pike.pond.sub.org> In-Reply-To: <87ocx6pkol.fsf@pike.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902131333.47141.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 Cc: devicetree-discuss@ozlabs.org, Markus Armbruster > Hypothetical example: say the kernel needs to know exactly how the > interrupts are wired. But QEMU can wire the interrupts just one way, > the way it has always wired them. What's the point in putting that way > into the machine configuration? Verifying that whatever is there > matches reality is no less work than generating the information from > scratch, isn't it? Much of the reason for having a machine config is that it allows control over things like interrupt routing. Particularly for embedded machines, it's common to have a variety of different machines all using the same components, but varying in how those components are connected. For example the ARM Integrator, Versatile, Realview and Luminary Stellaris boards are all based on approximately the same basic set of devices (the ARM PrimeCell SoC peripherals), just with different memory maps and interrupt topologies. I suspect the same is true for many of the PPC, SH4 and ColdFire boards, and probably the different SPARC sun4m/sun4u variants. Most of the intrastructure to do modular machine construction is already there in qemu, it's just currently driven by hardcoded C QEMUMachineInitFunc rather than a runtime config. I guess that's where I see the distinction. Roughly speaking the "machine config" replaces pc.c:pc_init1, and the "user config" replaces a lot of the goo in vl.c:main, drive_init, etc. Paul