Tips for module_init() dependencies

[Gregory Haskins]

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

Attachment: signature.asc
Description: OpenPGP digital signature