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

[James Lentini]

After reading through the kernel sources, I believe that builtin 
module initialization functions are called by the do_initcalls 
function in init/main.c.

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

Can anyone confirm any of the information above?

james

On Mon, 9 May 2005, James Lentini wrote:

>
> Tom,
>
> If you are interested, there is one more thing you could look
> into/give me advice on:
>
> The dat module currently keeps track of its "state" (see the
> DAT_REGISTRY_STATE enumeration). The registry uses this information to
> detect the case when a provider or consumer calls a dat registry
> function before the registry's init function (dat_init) has run.
>
> Do we need to protect against this in the kernel?
>
> This situation could occur in usersapce when the registry, providers,
> and consumers could be shared libraries and the library initialization
> functions were invoked in an arbitrary order.
>
> I suspect that we can remove the code, but I wanted to make sure. If
> the dat registry, dat provider, and a consumer (e.g. NFS-RDMA) were
> built statically as part of the kernel, would the initialization
> functions be automatically run in the correct order?
>
> james
>
> On Mon, 9 May 2005, Tom Duffy wrote:
>
> tduffy> On Mon, 2005-05-09 at 14:06 -0400, James Lentini wrote:
> tduffy> > Committed revision 2287.
> tduffy> >
> tduffy> > On Fri, 6 May 2005, Tom Duffy wrote:
> tduffy> >
> tduffy> > tduffy> James, thanks for applying my last patch.
> tduffy> > tduffy>
> tduffy> > tduffy> You know where I am going with this... this is the first in what will be
> tduffy> > tduffy> a huge amount of patches.  I am happy to go through and send them all to
> tduffy> > tduffy> the list, but it might be quicker and easier for you to do it directly
> tduffy> > tduffy> to your tree for all the structs and enums.  Sup to you.
> tduffy> > tduffy>
> tduffy>
> tduffy> So, did you want me to continue with sending these type of patches?
> tduffy>
> tduffy> -tduffy
> tduffy>