[openib-general] [KDAPL] module initialization order (was Re: [PATCH] kDAPL: remove typedef DAT_PROVIDER)

[James Lentini]

On Tue, 10 May 2005, Grant Grundler wrote:

> On Tue, May 10, 2005 at 01:20:49PM -0400, James Lentini wrote:
>>
>> After reading through the kernel sources, I believe that builtin
>> module initialization functions are called by the do_initcalls
>> function in init/main.c.
>
> correct
>
>> I haven't conclusively determined how the initialization order is
>> specified. From what I've gleamed from mailing list archives, the
>> module initialization order was determined by link order.
>
> There are several "classes" of init modules that dictate
> a coarse level of ordering inside the list of init routines.
> See the list of *_initcall() macros in include/linux/init.h.

Are the *_initcall() macros intended for code that can be compiled 
both as part of the kernel or as a loadable module? I see module_init 
being used in these instances.

>> As a result the relative position of the obj-$(CONFIG_XXX) lines in 
>> Makefiles determined the order of module initialization. Often when 
>> I found discussion of this topic, it was in the context of changing 
>> this scheme to make the initialization dependencies explicit. 
>> However, it does not appear that this was ever done.
>>
>> One final piece of information that I came across is that the order of
>> initialization functions in the System.map file is the order that they
>> will be called in.
>
> yup - but it's very arch specific and compile option specific
> as to what the final order will be. If there is a strong dependency
> within a class, one can fix this by directly calling the init routine
> of the module is needed by another module. A (bad) example might be
> suckyio^Wsuperio support on parisc platforms.
>
>> Can anyone confirm any of the information above?
>
> hth,
> grant
>