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>
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
