I see what the problem is. In the case of slurm, I don't want -any- components to be opened, even though I am going to call plm open/select. I have to leave that logic in place for those environments that -do- want to specify some backend secondary launcher.
So the question is: how do I tell mca_component_open "do not open anything"? If we don't have a mechanism for doing that, can we create one? On 5/2/08 8:02 AM, "Ralph Castain" <r...@lanl.gov> wrote: > Well, I have a current version of the trunk. I add an MCA param to the > environment indicating that only rsh is to be used by the orted. Yet I get > an output from every orted indicating that slurm (misspelled!) is available > for selection. > > This tells me that the slurm component is being opened, even though the > param is set. > > I can check again to ensure that the param is set... > > > On 5/2/08 7:53 AM, "Jeff Squyres" <jsquy...@cisco.com> wrote: > >> (moving to devel list for wider audience) >> >> Hmm. I thought the UTK stuff from a while ago supposedly changed this >> behavior to only open the components that were specifically requested. >> >> This behavior looks like the *original* MCA behavior -- open them all, >> then discard what we don't want (but doesn't necessarily reclaim the >> memory because of how dlclose works). >> >> >> On May 2, 2008, at 9:48 AM, Ralph Castain wrote: >> >>> Yo guys >>> >>> I've noticed something on the trunk that just doesn't strike me as >>> correct. >>> If I specify "-mca plm rsh", it is my expectation that (a) only the >>> rsh >>> component will be opened, and (b) only the rsh module will be >>> selected, >>> unless that component indicates that it cannot run. >>> >>> What I am seeing, though, is that -all- the plm components are being >>> opened. >>> This is not only unnecessary, but consumes memory and leads to >>> concern over >>> whether or not some other module could become active. >>> >>> Is this the intended behavior? If so, may I suggest we change it in >>> Josh's >>> branch prior to bringing it over? >>> >>> Ralph >>> >>> >> > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
