On May 17, 2010, at 7:59 PM, Barrett, Brian W wrote:
> HWLOC could be extended to support Red Storm, probably, but we don't have the
> need or time to do such an implementation.
Fair enough.
> Given that, I'm not really picky about what the method of not breaking an
> existing supported platform is, but I think having HAVE_HWLOC defines
> everywhere is a bad idea...
We need a mechanism to have hwloc *not* be there, particularly for embedded
environments -- where hwloc would add no value. This is apparently just like
Red Storm, but even worse because we need to keep the memory footprint down as
much as possible (libhwloc.so.0.0 on linux is 104KB -- libhwloc.a is 139KB --
both are big numbers when you only have a few MB of usable RAM). So even
leaving stubs doesn't seem like a good idea -- they'll take up space, too. And
the hwloc API is fairly large -- maintaining stubs for all the API functions
could be a daunting task.
I think embedding is the main reason I can't think of any better idea than #if
OPAL_HAVE_HWLOC.
I anticipate that hwloc usage would be fairly localized in the OMPI code base:
int btl_sm_setup_stuff(...)
{
#if OPAL_HAVE_HWLOC
...do interesting hwloc things...
...setup stuff on btl_sm_component...
btl_sm_component.have_hwloc = 1;
#else
btl_sm_component.have_hwloc = 0;
#endif
}
int btl_sm_other_stuff(...)
{
if (btl_sm_component.have_hwloc) {
...use the hwloc info...
}
}
But I'm certainly open to other ideas -- got any?
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
