From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lpj9X-0004oh-Kj for qemu-devel@nongnu.org; Fri, 03 Apr 2009 09:09:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lpj9S-0004io-LD for qemu-devel@nongnu.org; Fri, 03 Apr 2009 09:09:46 -0400 Received: from [199.232.76.173] (port=60542 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lpj9S-0004ib-87 for qemu-devel@nongnu.org; Fri, 03 Apr 2009 09:09:42 -0400 Received: from mx20.gnu.org ([199.232.41.8]:54391) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lpj9R-0001wW-Gs for qemu-devel@nongnu.org; Fri, 03 Apr 2009 09:09:41 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lpj9L-0005e4-Va for qemu-devel@nongnu.org; Fri, 03 Apr 2009 09:09:36 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [RFC] Introduce module API to QEMU Date: Fri, 3 Apr 2009 13:09:32 +0000 References: <1238724755-15929-1-git-send-email-aliguori@us.ibm.com> <200904031235.33157.paul@codesourcery.com> <49D607A3.7040907@codemonkey.ws> In-Reply-To: <49D607A3.7040907@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904031409.32792.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 On Friday 03 April 2009, Anthony Liguori wrote: > Paul Brook wrote: > >> This patch introduces a module API similar to what's in the Linux > >> kernel. This includes module_init/module_exit functions that register > >> functions that are run at init and exit respectively. > > > > Wouldn't it be much simpler to just have a list of device names, and > > assume the each device is implemented in $devicename., and provides > > $devicename_register ? > > > > It's then an extremely simple shell script to collate and call these. > > It doesn't generalize very well. For instance, the VNC server is not a > device but it needs to be able to register as a DisplayState backend. Hmm, this raises annother issue - we've got to be extremely careful about ordering. It's not inconcievable that the PCI support code would have constructors (e.g. to register a PCI bus type). Paul