Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] First plugin namespace issue report
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2013-06-04 08:11:48

(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 <Brice.Goglin_at_[hidden]> 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 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.