From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXypT-0002Hx-Ua for qemu-devel@nongnu.org; Fri, 13 Feb 2009 09:15:44 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXypS-0002H1-SC for qemu-devel@nongnu.org; Fri, 13 Feb 2009 09:15:43 -0500 Received: from [199.232.76.173] (port=36917 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXypS-0002Gl-I3 for qemu-devel@nongnu.org; Fri, 13 Feb 2009 09:15:42 -0500 Received: from mx2.redhat.com ([66.187.237.31]:36588) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LXypS-0008BX-0x for qemu-devel@nongnu.org; Fri, 13 Feb 2009 09:15:42 -0500 Subject: Re: [Qemu-devel] [RFC] Machine description as data References: <87iqnh6kyv.fsf@pike.pond.sub.org> <200902131206.42427.paul@codesourcery.com> <87ocx6pkol.fsf@pike.pond.sub.org> <200902131333.47141.paul@codesourcery.com> From: Markus Armbruster Date: Fri, 13 Feb 2009 15:13:36 +0100 In-Reply-To: <200902131333.47141.paul@codesourcery.com> (Paul Brook's message of "Fri\, 13 Feb 2009 13\:33\:46 +0000") Message-ID: <871vu2pgq7.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: Paul Brook Cc: devicetree-discuss@ozlabs.org, qemu-devel@nongnu.org Paul Brook writes: >> 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. We make stuff configurable in QEMU when we need it more than one way. While the kernel wants to see configuration when it could conceivably exist in more than one way. > 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 Not that I disagree with that. Look, my goals are rather modest. I want to start where we are, put devices behind a nice abstract interface one by one, picking apart the pc.c hairball on the way. The idea is not to design the perfect, all-encompassing abstract device interface, just to capture what we need, and extend as we go. The abstract device interface makes a simple machine builder possible, driven by tree-structured configuration. That in turn makes it easier to make things configurable. Which can be expected to lead to more configurability, when and where there's a need for it. All this can be done in nice, safe baby steps. I don't need to come up with an all-singing machine description fit for a picky kernel before I can start doing something useful. Now, if you hand me such a configuration on a platter, I'd be a fool not to take it. The catch: I need one for a PC. I believe there's significant overlap in what we two want to accomplish. We just come from different directions, with somewhat differing priorities.