Open MPI logo

Hardware Locality Development Mailing List Archives

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

Subject: Re: [hwloc-devel] merging plugins?
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2012-09-25 05:07:41

Le 25/09/2012 10:48, Samuel Thibault a écrit :
> Le 25/09/2012 09:49, Samuel Thibault a écrit :
>>> One thing which can be confusing for the user is that core_linux goes
>>> to the core os list while core_libpci goes to the additional list. It
>>> would probably be better to use a different class name. I actually don't
>>> currently understand what classes are used for.
>> The class name was initially used to distinguish between normal (core)
>> plugins and xml backends. It may be possible to completely remove it now
>> that component struct have a type, I'll check.
> Ok. I was also hit by the fact that core_linux_x86 is not valid, only
> one '_' is allowed.

Right, this check doesn't make much sense anymore. I am removing it.

>> We have the "core_xml" component (generic xml support) and "xml_libxml"
>> + "xml_nolibxml" backends behind that. I am fine with removing the
>> "core_" prefix, but I wonder if we should keep the "xml_" prefix for the
>> latter.
> I'd say we should keep it. Just like I wanted to use core_linux_x86 (as
> opposed to core_linux)

Keep which one? "core" or "core" and "xml" ?

> Well, that still looks hardcoded to me. Actually, a simple way would
> be to order all plugins in just one list by priorities. When loading a
> plugin, one checks whether the exclusion point of the plugin was
> already filled or not, and load the plugin accordingly

The good thing about this is that XML and synthetic can set exclusion
But we obviously don't want cuda, ... to set the ADDITIONAL exclusion
flag. So setting a exclusion flag would mean "I don't want any plugin of
this type to be enabled" (different from "I don't want any plugin with
this exclusion flag to be set).

>> We should hide xml backends/plugins as much as possible in the doc, we
>> have old env variables to deal with those, no need to tell people that
>> the way it works changed internally.
> You are talking about xml only, not other plugins, right? Well, I
> believe it still makes sense to expose the xml ones as loadable just
> like the linuxx86 plugin is, or even a user-provided plugin.

Yes only talking about XML.