From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Lpk6R-0002yT-Al
	for qemu-devel@nongnu.org; Fri, 03 Apr 2009 10:10:39 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Lpk6M-0002wp-8P
	for qemu-devel@nongnu.org; Fri, 03 Apr 2009 10:10:38 -0400
Received: from [199.232.76.173] (port=48952 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Lpk6M-0002wj-3g
	for qemu-devel@nongnu.org; Fri, 03 Apr 2009 10:10:34 -0400
Received: from rv-out-0708.google.com ([209.85.198.242]:44292)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1Lpk6L-0003kP-OW
	for qemu-devel@nongnu.org; Fri, 03 Apr 2009 10:10:33 -0400
Received: by rv-out-0708.google.com with SMTP id l33so969159rvb.22
	for <qemu-devel@nongnu.org>; Fri, 03 Apr 2009 07:10:32 -0700 (PDT)
Message-ID: <49D618D3.90904@codemonkey.ws>
Date: Fri, 03 Apr 2009 09:10:27 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [RFC] Introduce module API to QEMU
References: <1238724755-15929-1-git-send-email-aliguori@us.ibm.com>
	<200904031235.33157.paul@codesourcery.com>
	<49D607A3.7040907@codemonkey.ws>
	<200904031409.32792.paul@codesourcery.com>
In-Reply-To: <200904031409.32792.paul@codesourcery.com>
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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org

Paul Brook wrote:
> 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).
>   

That's one reason I started with section instead of constructor.  You 
can control when you initialize with section which means you could have 
multiple types of constructors that allowed some form of ordering.  
Linux allows this via various *_initcall() methods.

Regards,

Anthony Liguori

> Paul
>