From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Lpmwf-00079B-NS
	for qemu-devel@nongnu.org; Fri, 03 Apr 2009 13:12:45 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Lpmwa-00075O-99
	for qemu-devel@nongnu.org; Fri, 03 Apr 2009 13:12:44 -0400
Received: from [199.232.76.173] (port=48788 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Lpmwa-00075G-3A
	for qemu-devel@nongnu.org; Fri, 03 Apr 2009 13:12:40 -0400
Received: from mail-bw0-f172.google.com ([209.85.218.172]:60956)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <blauwirbel@gmail.com>) id 1LpmwZ-0004RY-FQ
	for qemu-devel@nongnu.org; Fri, 03 Apr 2009 13:12:39 -0400
Received: by bwz20 with SMTP id 20so960621bwz.34
	for <qemu-devel@nongnu.org>; Fri, 03 Apr 2009 10:12:38 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <49D607A3.7040907@codemonkey.ws>
References: <1238724755-15929-1-git-send-email-aliguori@us.ibm.com>
	<200904031235.33157.paul@codesourcery.com>
	<49D607A3.7040907@codemonkey.ws>
Date: Fri, 3 Apr 2009 20:12:38 +0300
Message-ID: <f43fc5580904031012v2b1d22abr6764cfdd9ddebe1d@mail.gmail.com>
Subject: Re: [Qemu-devel] [RFC] Introduce module API to QEMU
From: Blue Swirl <blauwirbel@gmail.com>
Content-Type: text/plain; charset=UTF-8
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: qemu-devel@nongnu.org

On 4/3/09, Anthony Liguori <anthony@codemonkey.ws> 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.
>
>  The other way to do this typically is to have module_init() functions that
> turn a function into a non-static function with some sort of annotation that
> disappears at compile time.  For instance:
>
>  module_init(virtnet_init);
>
>  Would become:
>
>  int qemu__module__init__virtnet_init(void)
>  {
>     return virtnet_init();
>  }
>
>  with #define qemu__init__function
>
>  You then have something that searches for these functions.  The problem
> with this approach is that virtnet_init must be a unique name because it's a
> non-static.  You can add some uniqueness by playing with __LINE__ but that
> doesn't make any guarantees.

The shell script could analyze the module files before compiling and
generate a .h file which contains #defines for the names of the
exported functions. The names can be made unique for example by
prepending the file name with some munging with tr.

This .h file would be included by the module when compiling, it
defines how the exported functions should be named.