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