From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1VMt-0004Lm-0w for qemu-devel@nongnu.org; Tue, 05 May 2009 20:52:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1VMo-0004La-8u for qemu-devel@nongnu.org; Tue, 05 May 2009 20:52:14 -0400 Received: from [199.232.76.173] (port=33641 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1VMo-0004LX-2c for qemu-devel@nongnu.org; Tue, 05 May 2009 20:52:10 -0400 Received: from mx20.gnu.org ([199.232.41.8]:20880) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M1VMn-0007LA-RI for qemu-devel@nongnu.org; Tue, 05 May 2009 20:52:09 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M1VMj-0002nW-Us for qemu-devel@nongnu.org; Tue, 05 May 2009 20:52:06 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [RFC] New device API Date: Wed, 6 May 2009 01:52:01 +0100 References: <200905051231.09759.paul@codesourcery.com> <4A0083F5.7050606@codemonkey.ws> In-Reply-To: <4A0083F5.7050606@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905060152.02351.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > > The attached patch is my attempt at a new internal API for device > > creation in qemu. > > Instead of recreating constructors, I think we should just use GCC's > constructor attribute. This gives us ordering which will be important > when dealing with buses. The reason I'm not using constructors is because you have to workaround ordering issues. All constructors are run before main(), so there's a very limited amount they can actually do, and constructor priorities are not available on all hosts. > I think the layering is not quite right with qdev. > > Not all devices fit into the parameters of register_mmio/connect_irq. > When dealing with bus devices (like PCI devices), I think you really > have to model the constructs that the bus expose. Note, this starts to > look very similar to the Linux kernel's layered device model. > > For instance, the following makes sense to me (from an x86 perspective): > Hmm, I'll think about this a bit. Paul