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

[James Lentini]

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

That situation could be viewed as a configuration error. I think 
we can use the kconfig language to prevent this. 

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

Currently when a consumer (either one built into the kernel or a 
loadable module) attempts to open an IA that does not exist it will 
receive a "not found" error. The DAT specification's "static registry" 
provided a mechanism for loading a provider on demand. This part of 
the spec hasn't been implemented for the kernel yet, but I think it 
would solve this problem.

itamar> 
itamar>  Itamar
itamar> 
itamar> > -----Original Message-----
itamar> > From: James Lentini [mailto:jlentini at netapp.com]
itamar> > Sent: Tuesday, May 10, 2005 8:21 PM
itamar> > To: openib-general at openib.org
itamar> > Cc: Tom Duffy
itamar> > Subject: [openib-general] [KDAPL] module initialization order (was Re:
itamar> > [PATCH] kDAPL: remove typedef DAT_PROVIDER)
itamar> > 
itamar> > 
itamar> > 
itamar> > After reading through the kernel sources, I believe that builtin 
itamar> > module initialization functions are called by the do_initcalls 
itamar> > function in init/main.c.
itamar> > 
itamar> > I haven't conclusively determined how the initialization order is 
itamar> > specified. From what I've gleamed from mailing list archives, the 
itamar> > module initialization order was determined by link order. As a result 
itamar> > the relative position of the obj-$(CONFIG_XXX) lines in Makefiles 
itamar> > determined the order of module initialization. Often when I found 
itamar> > discussion of this topic, it was in the context of changing this 
itamar> > scheme to make the initialization dependencies explicit. However, it 
itamar> > does not appear that this was ever done.
itamar> > 
itamar> > One final piece of information that I came across is that the 
itamar> > order of 
itamar> > initialization functions in the System.map file is the order 
itamar> > that they 
itamar> > will be called in.
itamar> > 
itamar> > Can anyone confirm any of the information above?
itamar> > 
itamar> > james
itamar> > 
itamar> > On Mon, 9 May 2005, James Lentini wrote:
itamar> > 
itamar> > >
itamar> > > Tom,
itamar> > >
itamar> > > If you are interested, there is one more thing you could look
itamar> > > into/give me advice on:
itamar> > >
itamar> > > The dat module currently keeps track of its "state" (see the
itamar> > > DAT_REGISTRY_STATE enumeration). The registry uses this 
itamar> > information to
itamar> > > detect the case when a provider or consumer calls a dat registry
itamar> > > function before the registry's init function (dat_init) has run.
itamar> > >
itamar> > > Do we need to protect against this in the kernel?
itamar> > >
itamar> > > This situation could occur in usersapce when the registry, 
itamar> > providers,
itamar> > > and consumers could be shared libraries and the library 
itamar> > initialization
itamar> > > functions were invoked in an arbitrary order.
itamar> > >
itamar> > > I suspect that we can remove the code, but I wanted to make sure. If
itamar> > > the dat registry, dat provider, and a consumer (e.g. NFS-RDMA) were
itamar> > > built statically as part of the kernel, would the initialization
itamar> > > functions be automatically run in the correct order?
itamar> > >
itamar> > > james
itamar> > >
itamar> > > On Mon, 9 May 2005, Tom Duffy wrote:
itamar> > >
itamar> > > tduffy> On Mon, 2005-05-09 at 14:06 -0400, James Lentini wrote:
itamar> > > tduffy> > Committed revision 2287.
itamar> > > tduffy> >
itamar> > > tduffy> > On Fri, 6 May 2005, Tom Duffy wrote:
itamar> > > tduffy> >
itamar> > > tduffy> > tduffy> James, thanks for applying my last patch.
itamar> > > tduffy> > tduffy>
itamar> > > tduffy> > tduffy> You know where I am going with this... 
itamar> > this is the first in what will be
itamar> > > tduffy> > tduffy> a huge amount of patches.  I am happy to 
itamar> > go through and send them all to
itamar> > > tduffy> > tduffy> the list, but it might be quicker and 
itamar> > easier for you to do it directly
itamar> > > tduffy> > tduffy> to your tree for all the structs and 
itamar> > enums.  Sup to you.
itamar> > > tduffy> > tduffy>
itamar> > > tduffy>
itamar> > > tduffy> So, did you want me to continue with sending these 
itamar> > type of patches?
itamar> > > tduffy>
itamar> > > tduffy> -tduffy
itamar> > > tduffy>
itamar> > _______________________________________________
itamar> > openib-general mailing list
itamar> > openib-general at openib.org
itamar> > http://openib.org/mailman/listinfo/openib-general
itamar> > 
itamar> > To unsubscribe, please visit 
itamar> > http://openib.org/mailman/listinfo/openib-general
itamar> > 
itamar>