Re: [hwloc-devel] -lhwloc in components.
I agree -- all of the things you mention are do-able. But it's a whole lot more bookkeeping and care/feeding to ensure that nothing goes wrong vs. just calling a hwloc core function and assuming it's there. Such things will require maintenance over time. In the end -- it's a tradeoff: - do we want the maintenance associated with a struct full of core function pointers? or - do we want to use the solution I mentioned in http://www.open-mpi.org/community/lists/hwloc-devel/2012/09/3253.php? Both have strengths / weaknesses. On Sep 5, 2012, at 11:25 AM, Samuel Thibault wrote: > Jeff Squyres, le Wed 05 Sep 2012 17:13:56 +0200, a écrit : >>> The source code shouldn't need to be modified: >>> >>> #define hwloc_foo_bar(arg1, arg2) hwloc_funcs->foo_bar(arg1, arg2) >> >> You need to make sure that #define is only effected in certain places in the >> code. > > Well, all the places that will constitute a plugin, no? > >> And you need to ensure that hwloc_funcs->[foo] isn't attempted to be used >> before it has been filled in. > > As I said in my earlier mail, hwloc_funcs would be provided by the > loader of the plugin, so it can make sure it's filled in (I forgot to > mention that what I call hwloc_funcs above is an internal variable of > the plugin, not a symbol provided by libhwloc.so). > >> And unless there is a very fixed set of functions that can be called by >> plugins, > > Well, I believe we'll have to have that anyway. That was part of the > whole discussion about plugins a long time ago. > >> you'll probably need to grow hwloc_funcs over time, which may lead to ABI >> issues...? > > Sure. We can for instance make the plugin check for the size of > hwloc_funcs provided by the plugin loader vs the size that it was > compiled against, and thus refuse to get loaded by an older hwloc. > > Samuel > ___ > hwloc-devel mailing list > hwloc-de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [hwloc-devel] -lhwloc in components.
On Sep 5, 2012, at 11:08 AM, Samuel Thibault wrote: >> No. It's not really an ltdl issue. ltdl is just a portable wrapper around >> OS-specific dlopen-like mechanisms. > > I understand that, but dlopen is usually used for plugins, and plugins > usually need such kind of calling back into what loaded the plugin. Sure. It's really a matter of the linker scopes. IIRC, in a somewhat-recent version of ltdl (I don't remember the version offhand -- perhaps somewhere in the 2.2 series?), they changed the default of lt_dlopen to start opening plugins in private scopes, not the global scope. That's what has contributed to this hubaloo -- by default, plugins can no longer see the global scope, which is typically where the symbols are that they need to resolve (e.g., in the libhwloc.so that is linked in to lstopo). >>> One way would be to pass to the component a structure with all the >>> useful function pointers (using #define to keep the same source code). >> >> We thought about this in OMPI and decided it would be a nightmare in the >> source code. > > The source code shouldn't need to be modified: > > #define hwloc_foo_bar(arg1, arg2) hwloc_funcs->foo_bar(arg1, arg2) You need to make sure that #define is only effected in certain places in the code. And you need to ensure that hwloc_funcs->[foo] isn't attempted to be used before it has been filled in. And unless there is a very fixed set of functions that can be called by plugins, you'll probably need to grow hwloc_funcs over time, which may lead to ABI issues...? -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [hwloc-devel] -lhwloc in components.
Jeff Squyres, le Wed 05 Sep 2012 17:06:00 +0200, a écrit : > On Sep 5, 2012, at 10:21 AM, Samuel Thibault wrote: > > > So ltdl does not help for that matter? > > No. It's not really an ltdl issue. ltdl is just a portable wrapper around > OS-specific dlopen-like mechanisms. I understand that, but dlopen is usually used for plugins, and plugins usually need such kind of calling back into what loaded the plugin. > > One way would be to pass to the component a structure with all the > > useful function pointers (using #define to keep the same source code). > > We thought about this in OMPI and decided it would be a nightmare in the > source code. The source code shouldn't need to be modified: #define hwloc_foo_bar(arg1, arg2) hwloc_funcs->foo_bar(arg1, arg2) Samuel
