From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC] Introduce module API to QEMU
Date: Fri, 03 Apr 2009 07:57:07 -0500 [thread overview]
Message-ID: <49D607A3.7040907@codemonkey.ws> (raw)
In-Reply-To: <200904031235.33157.paul@codesourcery.com>
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.
This is doable but IMHO a worse solution. I'd rather use
__attribute__((constructor)) for now and introduce the above only if we
ever support something other than GCC.
Regards,
Anthony Liguori
> Paul
>
>
>
next prev parent reply other threads:[~2009-04-03 12:57 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-03 2:12 [Qemu-devel] [RFC] Introduce module API to QEMU Anthony Liguori
2009-04-03 2:29 ` malc
2009-04-03 3:36 ` Anthony Liguori
2009-04-03 3:48 ` malc
2009-04-03 12:59 ` Anthony Liguori
2009-04-03 17:00 ` malc
2009-04-03 17:31 ` Anthony Liguori
2009-04-03 17:46 ` malc
2009-04-03 17:59 ` M. Warner Losh
2009-04-03 17:58 ` M. Warner Losh
2009-04-03 18:05 ` Anthony Liguori
2009-04-03 20:12 ` Kevin Wolf
2009-04-03 18:30 ` malc
2009-04-03 7:08 ` Mark McLoughlin
2009-04-03 13:01 ` Anthony Liguori
2009-04-03 17:36 ` Anthony Liguori
2009-04-03 7:50 ` Avi Kivity
2009-04-03 11:35 ` Paul Brook
2009-04-03 12:57 ` Anthony Liguori [this message]
2009-04-03 13:09 ` Paul Brook
2009-04-03 14:10 ` Anthony Liguori
2009-04-03 14:11 ` Anthony Liguori
2009-04-03 14:28 ` Paul Brook
2009-04-03 14:53 ` Avi Kivity
2009-04-03 16:15 ` Anthony Liguori
2009-04-03 17:12 ` Blue Swirl
2009-04-03 14:04 ` Daniel Jacobowitz
2009-04-03 14:54 ` Avi Kivity
2009-04-03 15:10 ` Paul Brook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49D607A3.7040907@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).