Tips for module_init() dependencies

Tips for module_init() dependencies

[Gregory Haskins]

[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]

Re: Tips for module_init() dependencies

[Daniel Walker]

On Thu, 2009-10-15 at 09:01 -0400, Gregory Haskins wrote:

> 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.

You can't modify the build order so your module get "builtin" after
configfs?

Daniel 

Re: Tips for module_init() dependencies

[Gregory Haskins]

[-- Attachment #1: Type: text/plain, Size: 1467 bytes --]

Daniel Walker wrote:
> On Thu, 2009-10-15 at 09:01 -0400, Gregory Haskins wrote:
> 
>> 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.
> 
> You can't modify the build order so your module get "builtin" after
> configfs?
> 

Hi Daniel,

Possibly.

A) Any suggestions on how? Can I express this in Kconfig or something
(i.e. "depends on FOO").  I currently have "select FOO" in the BAR
object, but this doesn't seem to be sufficient to describe the relationship.

B) Do I have to make the entire chain follow suit? (I have C deps on B,
B deps on A kind of scenarios)

Kind Regards,
-Greg



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]

Re: Tips for module_init() dependencies

[Randy Dunlap]

On Thu, 15 Oct 2009 11:58:19 -0400 Gregory Haskins wrote:

> Daniel Walker wrote:
> > On Thu, 2009-10-15 at 09:01 -0400, Gregory Haskins wrote:
> > 
> >> 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.
> > 
> > You can't modify the build order so your module get "builtin" after
> > configfs?
> > 
> 
> Hi Daniel,
> 
> Possibly.
> 
> A) Any suggestions on how? Can I express this in Kconfig or something
> (i.e. "depends on FOO").  I currently have "select FOO" in the BAR
> object, but this doesn't seem to be sufficient to describe the relationship.

Not in Kconfig, only in Makefile(s).
and please put #comments in them explaining the ordering requirements/needs.

> B) Do I have to make the entire chain follow suit? (I have C deps on B,
> B deps on A kind of scenarios)
> 
> Kind Regards,
> -Greg


---
~Randy

Re: Tips for module_init() dependencies

[Gregory Haskins]

[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]

Randy Dunlap wrote:
> On Thu, 15 Oct 2009 11:58:19 -0400 Gregory Haskins wrote:
> 
>> Daniel Walker wrote:
>>> On Thu, 2009-10-15 at 09:01 -0400, Gregory Haskins wrote:
>>>
>>>> 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.
>>> You can't modify the build order so your module get "builtin" after
>>> configfs?
>>>
>> Hi Daniel,
>>
>> Possibly.
>>
>> A) Any suggestions on how? Can I express this in Kconfig or something
>> (i.e. "depends on FOO").  I currently have "select FOO" in the BAR
>> object, but this doesn't seem to be sufficient to describe the relationship.
> 
> Not in Kconfig, only in Makefile(s).
> and please put #comments in them explaining the ordering requirements/needs.

Hi Randy,

Something like this?

----------

# cat drivers/bar/Makefile

bar.o: foo.o
obj-$CONFIG_BAR += bar.o

----------

?

Kind Regards,
-Greg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]

Re: Tips for module_init() dependencies

[Randy Dunlap]

On Thu, 15 Oct 2009 12:13:30 -0400 Gregory Haskins wrote:

> Randy Dunlap wrote:
> > On Thu, 15 Oct 2009 11:58:19 -0400 Gregory Haskins wrote:
> > 
> >> Daniel Walker wrote:
> >>> On Thu, 2009-10-15 at 09:01 -0400, Gregory Haskins wrote:
> >>>
> >>>> 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.
> >>> You can't modify the build order so your module get "builtin" after
> >>> configfs?
> >>>
> >> Hi Daniel,
> >>
> >> Possibly.
> >>
> >> A) Any suggestions on how? Can I express this in Kconfig or something
> >> (i.e. "depends on FOO").  I currently have "select FOO" in the BAR
> >> object, but this doesn't seem to be sufficient to describe the relationship.
> > 
> > Not in Kconfig, only in Makefile(s).
> > and please put #comments in them explaining the ordering requirements/needs.
> 
> Hi Randy,
> 
> Something like this?
> 
> ----------
> 
> # cat drivers/bar/Makefile
> 
> bar.o: foo.o
> obj-$CONFIG_BAR += bar.o
> 
> ----------
> 
> ?

Just the order that they are listed in, either within one Makefile
or the order that a parent Makefile lists them, so:

obj-$CONFIG_FOO += foo.o
obj-$CONFIG_BAR += bar.o

That will fix the load/init ordering.  You may also need to specify
build dependencies in Kconfig file(s).


---
~Randy

Re: Tips for module_init() dependencies

[Daniel Walker]

On Thu, 2009-10-15 at 11:58 -0400, Gregory Haskins wrote:

> Hi Daniel,
> 
> Possibly.
> 
> A) Any suggestions on how? Can I express this in Kconfig or something
> (i.e. "depends on FOO").  I currently have "select FOO" in the BAR
> object, but this doesn't seem to be sufficient to describe the relationship.
> 
> B) Do I have to make the entire chain follow suit? (I have C deps on B,
> B deps on A kind of scenarios)

Yeah, what Randy said .. As far as I know it should be just a build
order issue .. In the make file when you specify your new module along
with all the others where you put it is actually important .. In
fs/Makefile you have this line,

obj-$(CONFIG_CONFIGFS_FS)       += configfs/

and I would guess you want yours after that line if your adding to that
makefile.

Daniel

Re: Tips for module_init() dependencies

[Gregory Haskins]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

Daniel Walker wrote:
> On Thu, 2009-10-15 at 11:58 -0400, Gregory Haskins wrote:
> 
>> Hi Daniel,
>>
>> Possibly.
>>
>> A) Any suggestions on how? Can I express this in Kconfig or something
>> (i.e. "depends on FOO").  I currently have "select FOO" in the BAR
>> object, but this doesn't seem to be sufficient to describe the relationship.
>>
>> B) Do I have to make the entire chain follow suit? (I have C deps on B,
>> B deps on A kind of scenarios)
> 
> Yeah, what Randy said .. As far as I know it should be just a build
> order issue .. In the make file when you specify your new module along
> with all the others where you put it is actually important .. In
> fs/Makefile you have this line,
> 
> obj-$(CONFIG_CONFIGFS_FS)       += configfs/
> 
> and I would guess you want yours after that line if your adding to that
> makefile.

Right, that makes sense.  However, the problem is that these
dependencies might not have anything to do with ./fs per se and
therefore would not necessarily be in the ./fs Makefile.  But I think
the Makefile dependency idea in general is the right approach, so I will
experiment with this suggestion.

Kind Regards,
-Greg



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]

Re: Tips for module_init() dependencies

[Daniel Walker]

On Thu, 2009-10-15 at 12:17 -0400, Gregory Haskins wrote:
> Daniel Walker wrote:
> > On Thu, 2009-10-15 at 11:58 -0400, Gregory Haskins wrote:
> > 
> >> Hi Daniel,
> >>
> >> Possibly.
> >>
> >> A) Any suggestions on how? Can I express this in Kconfig or something
> >> (i.e. "depends on FOO").  I currently have "select FOO" in the BAR
> >> object, but this doesn't seem to be sufficient to describe the relationship.
> >>
> >> B) Do I have to make the entire chain follow suit? (I have C deps on B,
> >> B deps on A kind of scenarios)
> > 
> > Yeah, what Randy said .. As far as I know it should be just a build
> > order issue .. In the make file when you specify your new module along
> > with all the others where you put it is actually important .. In
> > fs/Makefile you have this line,
> > 
> > obj-$(CONFIG_CONFIGFS_FS)       += configfs/
> > 
> > and I would guess you want yours after that line if your adding to that
> > makefile.
> 
> Right, that makes sense.  However, the problem is that these
> dependencies might not have anything to do with ./fs per se and
> therefore would not necessarily be in the ./fs Makefile.  But I think
> the Makefile dependency idea in general is the right approach, so I will
> experiment with this suggestion.

I think the order for the core stuff is,

kernel/ mm/ fs/ ipc/ security/ crypto/ block/

and that all comes before drivers/ , so your adding to kernel/ or mm/ ?

Daniel

Re: Tips for module_init() dependencies

[Gregory Haskins]

[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]

Daniel Walker wrote:
> On Thu, 2009-10-15 at 12:17 -0400, Gregory Haskins wrote:
>> Daniel Walker wrote:
>>> On Thu, 2009-10-15 at 11:58 -0400, Gregory Haskins wrote:
>>>
>>>> Hi Daniel,
>>>>
>>>> Possibly.
>>>>
>>>> A) Any suggestions on how? Can I express this in Kconfig or something
>>>> (i.e. "depends on FOO").  I currently have "select FOO" in the BAR
>>>> object, but this doesn't seem to be sufficient to describe the relationship.
>>>>
>>>> B) Do I have to make the entire chain follow suit? (I have C deps on B,
>>>> B deps on A kind of scenarios)
>>> Yeah, what Randy said .. As far as I know it should be just a build
>>> order issue .. In the make file when you specify your new module along
>>> with all the others where you put it is actually important .. In
>>> fs/Makefile you have this line,
>>>
>>> obj-$(CONFIG_CONFIGFS_FS)       += configfs/
>>>
>>> and I would guess you want yours after that line if your adding to that
>>> makefile.
>> Right, that makes sense.  However, the problem is that these
>> dependencies might not have anything to do with ./fs per se and
>> therefore would not necessarily be in the ./fs Makefile.  But I think
>> the Makefile dependency idea in general is the right approach, so I will
>> experiment with this suggestion.
> 
> I think the order for the core stuff is,
> 
> kernel/ mm/ fs/ ipc/ security/ crypto/ block/
> 
> and that all comes before drivers/ , so your adding to kernel/ or mm/ ?
> 
> Daniel
> 

Its currently in kernel, though I am not married to this location per se.

-Greg



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]