Open MPI logo

Hardware Locality Development Mailing List Archives

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

Subject: Re: [hwloc-devel] lstopo-nox strikes back
From: Samuel Thibault (samuel.thibault_at_[hidden])
Date: 2012-04-25 11:04:56

Jeff Squyres, le Wed 25 Apr 2012 17:03:01 +0200, a écrit :
> On Apr 25, 2012, at 10:58 AM, Samuel Thibault wrote:
> > It already adapts itself, here. The issue is that the user has to
> > install an X version to get potential for X support. Which brings X.
> > If you do this with plugins, and you want automatic adaptation to
> > whether X is there, you'll have to install the plugin (it can't install
> > itself magically). And then that brings X too...
> Yes, understood, but my point here is that there could be multiple hwloc packages -- one that installs the core and some base set of lstopo plugins (probably not cairo and X). And then secondary packages install lstopo's cairo and X plugins.
> Hence, a sysadmin can choose whether to have cairo/X support (because presumably they will both pull in bunches of dependencies).

I understand that too.

> But the user always runs "lstopo" and gets the choice of whatever outputs the sysadmin has chosen to install.

Which is quite different from what you said above :)
And it's what is already achieved by the current status.

> >> But if I'm in the minority, no problem...
> >>
> >> If I'm not, I can work on a patch to see if it would be horribly disruptive...
> >
> > It would most probably not be, we already use a backend style, so it's a
> > matter of putting the code in separate plugins.
> That was my assumption. I am guessing/assuming that it's a matter of:
> - adjusting configury to use libltdl
> - building the back-ends as DSOs, installing them


> - adapting the back-ends to advertise their function pointers neutrally

They should be more or less already doing that.

> - adding a bit of dlopen-based logic to find/load all available backends