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

[Itamar Rabenstein]

I still see problem when NFSoRDMA or any other dat consumer and dat will be
build statically 
but the dat_provider (ib,iwarp,...) will be build as a module.

who will protect the dat consumer ?
how will the dat consumer know that there is no dat_provider 
available when dat_provider modules are not loaded?

 Itamar

> -----Original Message-----
> From: James Lentini [mailto:jlentini at netapp.com]
> Sent: Tuesday, May 10, 2005 8:21 PM
> To: openib-general at openib.org
> Cc: Tom Duffy
> Subject: [openib-general] [KDAPL] module initialization order (was Re:
> [PATCH] kDAPL: remove typedef DAT_PROVIDER)
> 
> 
> 
> 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
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit 
> http://openib.org/mailman/listinfo/openib-general
>