From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXwoi-0000wA-Kv for qemu-devel@nongnu.org; Fri, 13 Feb 2009 07:06:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXwoh-0000vU-7Q for qemu-devel@nongnu.org; Fri, 13 Feb 2009 07:06:48 -0500 Received: from [199.232.76.173] (port=53407 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXwog-0000vN-TA for qemu-devel@nongnu.org; Fri, 13 Feb 2009 07:06:46 -0500 Received: from mx20.gnu.org ([199.232.41.8]:30301) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LXwog-000254-Dx for qemu-devel@nongnu.org; Fri, 13 Feb 2009 07:06:46 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LXwof-0002bY-5P for qemu-devel@nongnu.org; Fri, 13 Feb 2009 07:06:45 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [RFC] Machine description as data Date: Fri, 13 Feb 2009 12:06:41 +0000 References: <87iqnh6kyv.fsf@pike.pond.sub.org> <20090213003724.GA8104@yookeroo.seuss> <87ab8qr317.fsf@pike.pond.sub.org> In-Reply-To: <87ab8qr317.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: <200902131206.42427.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 > Now let's examine how QEMU machine configuration and FDT machine > descriptions for kernels are related. > > In a way, both can be regarded as copies of a complete machine > description with lots of stuff pruned. Except the complete machine > description doesn't exist. Because there is no use for it. > > FDT routinely prunes stuff like PCI and USB devices, because those are > better probed. > > QEMU configuration should certainly prune everything that is not > actually configurable. I'm not sure I agree here, or at least we may be talking past each other. IMHO the machine config should specify all the bits of the machine that don't really want to be exposed to the average user. e.g. the memory layout and interrupt routings, etc. We then have a seaparate user config file (possibly structured differently) which exposes things like host bindings for disks and network devices. It's all a bit muddy because the current commandline options effect both the devices present and the host bindings for the corresponding interfaces. While this seems like a good idea to start with, I'm not convinced this is actually a desirable feature. Certainly for embedded machines you want a fixed set of hardware. e.g. if we have a SoC with 3 UARTs we should always create those 3 devices, and it's not meaningful to have more. If the user doesn't specify sufficient -serial options then the remainder just get connected to /dev/null. Likewise there's a good argument for having the vlan and disc configuration be separate from creation of the NIC/HBA devices. One possibility is that it might actually make more sense to specify hot-pluggable devices (e.g. PCI and USB) in a sumilar way that they would be added at runtime, rather than trying to force them into a static tree. My implementation focsed on just the machine config, mostly ignoring the user config and host bindings. Paul