From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LjboU-00008X-MR for qemu-devel@nongnu.org; Tue, 17 Mar 2009 12:06:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LjboQ-00006F-9Y for qemu-devel@nongnu.org; Tue, 17 Mar 2009 12:06:46 -0400 Received: from [199.232.76.173] (port=55447 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LjboP-00006A-TJ for qemu-devel@nongnu.org; Tue, 17 Mar 2009 12:06:41 -0400 Received: from mx20.gnu.org ([199.232.41.8]:4721) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LjboN-0001KK-11 for qemu-devel@nongnu.org; Tue, 17 Mar 2009 12:06:40 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LjboB-00018M-IB for qemu-devel@nongnu.org; Tue, 17 Mar 2009 12:06:27 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Machine description as data prototype, take 6 Date: Tue, 17 Mar 2009 16:06:23 +0000 References: <87iqnh6kyv.fsf@pike.pond.sub.org> <87iqmed1ki.fsf@pike.pond.sub.org> In-Reply-To: <87iqmed1ki.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: <200903171606.23694.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 > * The memory driver is PC-specific. It should be generic and > data-driven, but getting there isn't quite as easy as it sounds. > Memory (and sometimes even holes) need to be allocated in just the > right order to ensure guest physical address equals host offset for > certain memory ranges. This is a bug elsewhere and should be fixed there. > +/* > + * Device life cycle: > + * > + * 1. Configuration: config() method runs after parent's. It should > + * initialize the device's private data from its configuration > + * sub-tree. It may edit the configuration sub-tree, and may declare > + * initialization ordering constraints with tree_require_named(). > + * 2. Initialization: init() method runs after parent's and after that > + * 3. Start: start() method runs, order is unspecified. Feels like there's at least one too many callbacks here. The "may edit the configuration sub-tree" also sounds wrong. Devices shouldn't be interacting with the config tree directly, they should just be requesting/exposing features. This should also mean we shouldn't need manual dependencies because all device interaction is explicit. Possibly this is a bit confused because you've still got all the device code lumped in the same file. It's hard to identify hacks for PC bits you've not implemented yet, machine/device independent code, per-device code, and hardcoded tree generation in lieu of an actual config file reader. Using ugly wrappers round the legacy interface doesn't help, especially for PCI devices where we already have an abstraction layer. Paul