From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXyzO-0001X5-GB for qemu-devel@nongnu.org; Fri, 13 Feb 2009 09:25:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXyzM-0001WH-NH for qemu-devel@nongnu.org; Fri, 13 Feb 2009 09:25:57 -0500 Received: from [199.232.76.173] (port=34384 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXyzM-0001WC-KV for qemu-devel@nongnu.org; Fri, 13 Feb 2009 09:25:56 -0500 Received: from mx20.gnu.org ([199.232.41.8]:32371) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LXyzM-0001HK-CT for qemu-devel@nongnu.org; Fri, 13 Feb 2009 09:25:56 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LXyzL-0006Im-Dh for qemu-devel@nongnu.org; Fri, 13 Feb 2009 09:25:55 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [RFC] Machine description as data Date: Fri, 13 Feb 2009 14:25:52 +0000 References: <87iqnh6kyv.fsf@pike.pond.sub.org> <200902131333.47141.paul@codesourcery.com> <871vu2pgq7.fsf@pike.pond.sub.org> In-Reply-To: <871vu2pgq7.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: <200902131425.53137.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: Markus Armbruster Cc: devicetree-discuss@ozlabs.org, qemu-devel@nongnu.org > 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 suspect these two goals may be contradictory. The PC machine is so hairy that you need a singing, dancing machine description to be able to describe it. OTOH if what you really want to do is configure the host binding side of things, then as I've mentioned before, I see that as been somewhat separate from the actual machine creation, and trying to combine the two is probably a mistake. I really don't want users to have to hack the machine config just to change the name of an image file. Paul