From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LaAR4-000357-Ed for qemu-devel@nongnu.org; Thu, 19 Feb 2009 10:03:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LaAR2-00033S-TZ for qemu-devel@nongnu.org; Thu, 19 Feb 2009 10:03:34 -0500 Received: from [199.232.76.173] (port=50616 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LaAR2-00033A-7d for qemu-devel@nongnu.org; Thu, 19 Feb 2009 10:03:32 -0500 Received: from mx20.gnu.org ([199.232.41.8]:53985) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LaAR1-0004HE-M0 for qemu-devel@nongnu.org; Thu, 19 Feb 2009 10:03:31 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LaAR0-00064n-CU for qemu-devel@nongnu.org; Thu, 19 Feb 2009 10:03:30 -0500 From: Paul Brook Subject: Re: [Qemu-devel] Machine description as data prototype, take 3 Date: Thu, 19 Feb 2009 15:03:27 +0000 References: <87iqnh6kyv.fsf@pike.pond.sub.org> <200902191353.47491.paul@codesourcery.com> <874oyq5vdk.fsf@pike.pond.sub.org> In-Reply-To: <874oyq5vdk.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: <200902191503.27994.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: > Paul Brook writes: > > 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 think I got the PC nastiness encapsulated in driver methods. I can > put them into a separate file if you think that would help. That would definitely help. In principle there should be no PC specific code. It should all be either generic code (in dt.c or similar), or device specific code (in the appropriate device implementations). Paul