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:[EMAIL PROTECTED] itamar> > Sent: Tuesday, May 10, 2005 8:21 PM itamar> > To: [email protected] 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> > [email protected] itamar> > http://openib.org/mailman/listinfo/openib-general itamar> > itamar> > To unsubscribe, please visit itamar> > http://openib.org/mailman/listinfo/openib-general itamar> > itamar> _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
