Re: [hwloc-devel] First plugin namespace issue report

[Jeff Squyres (jsquyres)]

On Jun 4, 2013, at 11:12 PM, Brice Goglin  wrote:

> This code has to be in the plugin for real, it obviously cannot be
> shared in the hwloc core, but putting it in a static inline in
> hwloc/plugins.h may still be OK?


I've written a Haiku in honor of the occasion:

Linkers are your friends
like a bully at recess
takes your lunch money.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] First plugin namespace issue report

[Jeff Squyres (jsquyres)]

On Jun 4, 2013, at 9:55 AM, Brice Goglin  wrote:

>> One option might be to try to lt_dlsym one of the hwloc symbols that you 
>> know you'll need in the plugin (or any public hwloc symbol, for that 
>> matter).  If ltdl_sym gets NULL back for the hwloc global symbol, then the 
>> plugin should disqualify itself and have itself unloaded (perhaps with some 
>> way of reporting what/why it did that).
> 
> lt_dlsym doesn't seem to accept special handles such as RTLD_DEFAULT
> like dlsym does, and we don't have a handle on hwloc. I don't see how to
> do that with lt_dlsym?


Can we lt_dlopen(NULL) to get a handle to this process?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] First plugin namespace issue report

[Brice Goglin]

Le 04/06/2013 14:34, Jeff Squyres (jsquyres) a écrit :
> On Jun 4, 2013, at 5:11 AM, Brice Goglin  wrote:
>
>> 2) custom test with ltdl: The program just silently fails to load hwloc
>> symbols. Equivalent to passing the topology flag above.
>
> One option might be to try to lt_dlsym one of the hwloc symbols that you know 
> you'll need in the plugin (or any public hwloc symbol, for that matter).  If 
> ltdl_sym gets NULL back for the hwloc global symbol, then the plugin should 
> disqualify itself and have itself unloaded (perhaps with some way of 
> reporting what/why it did that).
>

lt_dlsym doesn't seem to accept special handles such as RTLD_DEFAULT
like dlsym does, and we don't have a handle on hwloc. I don't see how to
do that with lt_dlsym?

Brice

Re: [hwloc-devel] First plugin namespace issue report

[Jeff Squyres (jsquyres)]

On Jun 4, 2013, at 5:22 AM, Brice Goglin  wrote:

> I take that back. Topology flags come too late, plugins are loaded
> during the first topology_init().

Bummer.

> We're back to things like "export HWLOC_PLUGINS_PATH=/none"

Perhaps add a pre-init API to set flags like this...?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] First plugin namespace issue report

[Jeff Squyres (jsquyres)]

On Jun 4, 2013, at 5:11 AM, Brice Goglin  wrote:

> 2) custom test with ltdl: The program just silently fails to load hwloc
> symbols. Equivalent to passing the topology flag above.


One option might be to try to lt_dlsym one of the hwloc symbols that you know 
you'll need in the plugin (or any public hwloc symbol, for that matter).  If 
ltdl_sym gets NULL back for the hwloc global symbol, then the plugin should 
disqualify itself and have itself unloaded (perhaps with some way of reporting 
what/why it did that).

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] First plugin namespace issue report

[Brice Goglin]

Le 04/06/2013 14:11, Brice Goglin a écrit :
> Adding topology flag to disable plugin may indeed be a nice workaround.
> As long as the hwloc user doesn't need what's in plugin, things will
> work fine. And I think things will work fine in the OpenCL case.
>

I take that back. Topology flags come too late, plugins are loaded
during the first topology_init().
We're back to things like "export HWLOC_PLUGINS_PATH=/none"

Brice

Re: [hwloc-devel] First plugin namespace issue report

[Brice Goglin]

(adding the list to CC)


Le 04/06/2013 13:35, Jeff Squyres (jsquyres) a écrit :
> On Jun 4, 2013, at 4:10 AM, Brice Goglin  wrote:
>
>>> I guess I'm asking - why can't that plugin link against an embedded 
>>> (non-DSO) hwloc?
>> It can for sure. But if there's a hwloc package in your distrib (and
>> this one usually has plugins enabled), people usually force you to use
>> it instead of shipping another hwloc in your own package.
>
> Does hwloc support building its modules in libhwloc.la by default, but also 
> lt_dlopening any modules that it finds?
>
> If so, perhaps passing a flag to hwloc's init saying "don't open any plugins" 
> might be sufficient...?

Once you pass --enable-plugins to get plugin loading support, you can
still have both statically-built-in and plugin at the same time.

The main point for making hwloc plugins was to avoid dependencies on
crazy things like cuda/opencl/nvml/nvctrl/pci/libxml in the hwloc core.
So only these components can be built as plugins, others are always
static (Linux, x86, minimalistic xml without libxml).


Adding topology flag to disable plugin may indeed be a nice workaround.
As long as the hwloc user doesn't need what's in plugin, things will
work fine. And I think things will work fine in the OpenCL case.

Also, we have seen two behaviors:
1) OpenCL: the program aborts because the lazy symbol lookup fails, and
we can't easily force BIND_NOW
2) custom test with ltdl: The program just silently fails to load hwloc
symbols. Equivalent to passing the topology flag above.
I hope we'll see (2) more often than (1) in the future.

Brice