From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LaA1i-0000Ft-SL for qemu-devel@nongnu.org; Thu, 19 Feb 2009 09:37:23 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LaA1d-0000FK-Qm for qemu-devel@nongnu.org; Thu, 19 Feb 2009 09:37:19 -0500 Received: from [199.232.76.173] (port=36586 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LaA1d-0000F3-5M for qemu-devel@nongnu.org; Thu, 19 Feb 2009 09:37:17 -0500 Received: from mail-qy0-f20.google.com ([209.85.221.20]:36567) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LaA1c-0000iH-Py for qemu-devel@nongnu.org; Thu, 19 Feb 2009 09:37:16 -0500 Received: by qyk13 with SMTP id 13so802387qyk.10 for ; Thu, 19 Feb 2009 06:37:15 -0800 (PST) Message-ID: <499D6E7B.9080306@codemonkey.ws> Date: Thu, 19 Feb 2009 08:36:43 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Machine description as data prototype, take 3 References: <87iqnh6kyv.fsf@pike.pond.sub.org> <871vtuafdr.fsf@pike.pond.sub.org> In-Reply-To: <871vtuafdr.fsf@pike.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 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'm all for an early merge but I think there has to be enough of the architectural changes in place to allow other people to understand the long term direction and also contribute. I think the following are required for merge: 1) introduction of a new machine init function that returns a tree 2) code outside of dt.c, when -drive if=ide is specified, walks the tree looking for a node with an IDE decoration. Finds the appropriate master/slave primary/secondary slot, and hooks up the BlockDriverState to the IDE device. 3) reading the machine description from a file Basically, enough of the architecture that it's clear that we just need to do #2 for all of the remaining devices. I don't think your that far from this today. > New: > > * Rebased to git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6626 c046a42c-6fe2-441c-8c8c-71466251a162 > > * Code duplication cleaned up. I chose minimizing the impact on pc.c > over nice, clean interfaces. Happy to rework it if that was the wrong > choice. I think there are a few opportunities for cleanup that would > improve pc.c even without taking dt.c into consideration. I can work > on patches if you like. > > * The "device required" edges moved from struct tree to struct dt_device > to make the configuration tree more similar to FDTs structurally. > > * A bunch of pointless typedefs to hopefully blend in better > stylistically. Tabs expanded. If style issues remain, please point > them out to me! > I'll respond in a separate note but the style is still off. Regards, Anthony Liguori