From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1La9Lg-0005fy-Em for qemu-devel@nongnu.org; Thu, 19 Feb 2009 08:53:56 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1La9Ld-0005fm-Ew for qemu-devel@nongnu.org; Thu, 19 Feb 2009 08:53:54 -0500 Received: from [199.232.76.173] (port=44108 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1La9Ld-0005fj-7V for qemu-devel@nongnu.org; Thu, 19 Feb 2009 08:53:53 -0500 Received: from mx20.gnu.org ([199.232.41.8]:51696) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1La9Lc-0007CV-Ro for qemu-devel@nongnu.org; Thu, 19 Feb 2009 08:53:52 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1La9La-0003QE-U2 for qemu-devel@nongnu.org; Thu, 19 Feb 2009 08:53:51 -0500 From: Paul Brook Subject: Re: [Qemu-devel] Machine description as data prototype, take 3 (was: [RFC] Machine description as data) Date: Thu, 19 Feb 2009 13:53:47 +0000 References: <87iqnh6kyv.fsf@pike.pond.sub.org> <871vtuafdr.fsf@pike.pond.sub.org> In-Reply-To: <871vtuafdr.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: <200902191353.47491.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: Markus Armbruster On Thursday 19 February 2009, Markus Armbruster wrote: > Third iteration of the prototype. > > What about an early merge? If your answer to that is "yes, but", what > exactly do you want changed? I dislike that you've got everything lumped together. In its current form it's unclear that it's actually an improvement from what we currently have. There still seems to be an awful lot of code that's extremely PC specific, and I can't tell whether/which interfaces achieve separation from the legacy hardcoded PC nastyness and generic machine descriptions. I'm also worried that we have both user config (image files, vlans, etc) and machine description (devices instantiation, etc) described in the same place. I still believe these should be separate tasks, with clear boundaries between the two. Paul