[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AD71D12.9060203@gmail.com>
Date: Thu, 15 Oct 2009 09:01:06 -0400
From: Gregory Haskins <gregory.haskins@...il.com>
To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Tips for module_init() dependencies
Hi All,
General question about the best-practices for dealing with intermodule
initialization dependencies.
The problem I am seeing arises when two features are enabled as built-in
but are available also as modules.
For instance, say I have feature "foo" and "bar".
Foo may do:
---------
static int foostate;
foo()
{
/* do something with foostate */
}
EXPORT_SYMBOL_GPL(foo);
foo_init()
{
foostate = 0;
}
module_init(foo_init);
--------------
likewise, bar may do
--------------
bar_init()
{
foo();
}
module_init(bar_init);
--------------
If I build this system with
CONFIG_FOO=m
CONFIG_BAR=m
everything works, because modprobe will ensure that foo loads first
However:
CONFIG_FOO=y
CONFIG_BAR=y
may break, because the kernel seems to have no concept of
interdependency between foo_init() and bar_init(), and therefore
bar_init() may call foo() before foo_init() has executed.
There are various ways to solve this problem, such as deferring calling
foo() with a workqueue or something, but I was wondering if there was a
better/standard way to do this that I am missing?
The problem I am having specifically is that I am trying to call
configfs_register_subsystem() in a module_init(), but this breaks when
built into the kernel based on sheer bad luck that configfs gets
initialized after me. To date I have worked around this by forcing my
code to only support built-in, and using late_initcall() instead or
module_init. This works, but it only means I am putting the problem off
(code that depends on *me* has to use similar tricks, etc.
Any suggestions appreciated.
Kind Regards,
-Greg
Download attachment "signature.asc" of type "application/pgp-signature" (268 bytes)
Powered by blists - more mailing lists