Open MPI logo

Hardware Locality Development Mailing List Archives

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

Subject: Re: [hwloc-devel] v1.7
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2013-01-07 13:50:34


Le 07/01/2013 19:42, Brice Goglin a écrit :
> Le 07/01/2013 19:24, Jeff Squyres (jsquyres) a écrit :
>> On Jan 7, 2013, at 1:09 PM, Brice Goglin <Brice.Goglin_at_[hidden]>
>> wrote:
>>
>>> Your argument works for selecting among I/O components like
>>> cuda/nvml/opencl that are all independent (like several components in
>>> the same framework in OMPI). But it doesn't work when the order matters
>>> between components that discover the same things. Like "I want x86 first
>>> because it works better than the solaris component on my machine, and
>>> then the other usual components for to discover everything else".
>>>
>>> Remember that HWLOC_COMPONENTS="foo" means "foo first and then all the
>>> usual ones that do not conflict". It's not "only foo", which should be
>>> written as "foo,stop" (should be rare since the core excludes all
>>> conflicting components automatically).
>> Gotcha. I missed those two subtleties:
>>
>> 1. order matters
>> 2. there's an implicit "...and all the rest" at the end of the specification
>>
>> BTW, don't get me wrong -- I'm not against a different meaning than OMPI's. I was just trying to explain what OMPI uses an why.
>>
>> But that being said, having a "...and all the rest" implicitly implied at the end of the COMPONENTS specification is a little surprising (to me, IMHO). Perhaps you could have a special token that means "...and all the rest"? Perhaps:
>>
>> COMPONENTS=foo,bar,*
>>
> My first code did that (with "all" instead of "*" because come shells
> don't like * :)
> But my testing told me that there were many more cases where we want
> everything ("all") than nothing else ("stop"), so changed to "nothing else".
> But users are not going to play with the list of components very often
> anyway, so I think that'd be ok too.
>

Unfortunately, this syntax is already released in v1.6. Do we want to
break this in v1.7 ? Or in 1.6.1 ?

Brice