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
flags on OS+PCI+ADDITIONAL.
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.

Brice