The problem here is that if we keep out component approach we cannot use the full power of the hwloc API, except if we provide exactly the same. Clearly not a suitable approach.
How about we use one of the "obscure" features of hwloc (hwloc_topology_set_xml: loads an XML file describing a topology), which will force hwloc to load the configuration from the file instead of gathering it from the current environment. I can see two benefits with this approach: 1. we can freely use all hwloc API to gain access to the most obscure architectural features (and we need then if we really want to harness the full potential of current architectures). 2. we can simulate any other architecture as soon as we have a description file. So the current test module will be somehow supported with even more extensive capabilities. george. On May 15, 2010, at 12:19 , Jeff Squyres (jsquyres) wrote: > Oh, I mis-read your mail. Yes, leaving the "test" component is a friendly > amendment to this rfc. > > -jms > Sent from my PDA. No type good. > > ----- Original Message ----- > From: devel-boun...@open-mpi.org <devel-boun...@open-mpi.org> > To: Open MPI Developers <de...@open-mpi.org> > Sent: Sat May 15 09:02:28 2010 > Subject: Re: [OMPI devel] RFC: Remove all other paffinity components > > Umm...I vote "no". I still need that "test" component to use when testing > paffinity on machines that don't have all the required support (e.g., Mac). > > I don't have an opinion on the other components. > > > On May 13, 2010, at 6:20 PM, Jeff Squyres wrote: > >> WHAT: Remove all non-hwloc paffinity components. >> >> WHY: The hwloc component supports all those systems. >> >> WHERE: opal/mca/paffinity/[^hwloc|base] directories >> >> WHEN: for 1.5.1 >> >> TIMEOUT: Tuesday call, May 25 (yes, about 2 weeks from now -- let hwloc soak >> for a while...) >> >> ----------------------------------------------------------------------------- >> >> MORE DETAILS: >> >> As you probably noticed, I have (finally) committed the "hwloc" paffinity >> component to the trunk and removed the "linux" (i.e., PLPA) paffinity >> component: >> >> https://svn.open-mpi.org/trac/ompi/changeset/23125 >> https://svn.open-mpi.org/trac/ompi/changeset/23126 >> >> hwloc supports all systems that OMPI supports (and several that OMPI >> doesn't!) -- more specifically, it supports all the other systems that we >> have paffinity components for (darwin, linux, posix, solaris, windows). It >> can therefore fully replace all the other paffinity components. >> >> Indeed, the new hwloc's default priority is higher than all of the other >> current paffinity components, so over the next week or two, it'll be a good >> soak test to see if it is working properly. Once we get any kinks worked >> out, I propose removing all the other paffinity components and leaving only >> hwloc. >> >> That being said, we might as well leave the paffinity framework around, even >> if it only has one component left, simply on the argument that someday Open >> MPI may support a platform that hwloc does not. >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
