I believe we already have a way of defining where to get the default mca params:

    ret = mca_base_var_register ("opal", "mca", "base", "param_files", "Path 
for MCA "
                                 "configuration files containing variable 
values",
                                 MCA_BASE_VAR_TYPE_STRING, NULL, 0, 0, 
OPAL_INFO_LVL_2,
                                 MCA_BASE_VAR_SCOPE_READONLY, 
&mca_base_var_files);


So wouldn't it be as easy as defining an envar? It's what we did when using the 
OMPI code with ORCM a couple of years ago, and we used it again for a recent 
project in Greenplum where the default mca param was specified in a different 
location than usual.


On May 7, 2013, at 6:28 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> wrote:

> Given Ralph's questions about 
> rhttps://svn.open-mpi.org/trac/ompi/changeset/28456, ORNL's second question 
> to me/Nathan about MCA params is probably worth forwarding to the list -- see 
> below.
> 
> Thoughts on this proposal?
> 
> 
> Begin forwarded message:
> 
>> From: "Boehm, Swen" <bo...@ornl.gov>
>> Subject: Re: Q: project based MCA param files
>> Date: May 3, 2013 5:03:43 PM EDT
>> To: "Jeff Squyres (jsquyres)" <jsquy...@cisco.com>
>> Cc: Nathan Hjelm <hje...@lanl.gov>, "Vallee, Geoffroy R." 
>> <valle...@ornl.gov>, "Naughton III, Thomas J." <naught...@ornl.gov>
>> 
>> Hi Jeff,
>> 
>> Here is a short description of the enhancement we would like to contribute.
>> Let us know what you think.
>> 
>> The purpose of the suggested improvements is to enable "projects" to read
>> MCA parameters from project specific locations. This enables the usage
>> of OPAL and the MCA Frameworks outside the OpenMPI project without
>> interfering with OpenMPI specific parameters and removes the need to 
>> patch OPAL (e.g., to pick up params from different locations).
>> 
>> The possible scenarios would be the following:
>> 
>> a) adding the option to pick up a project specific mca-param.conf file
>>  Example:
>>           $HOME/.mca/${project}-mca-param.conf
>>   and     /etc/mca/${project}-mca-param.conf)
>> 
>> b) add the option to pick up the mca-param.conf file from a project specific
>>  directory
>>  Example:
>>           $HOME/.${project}/mca-param.conf
>>   and     /etc/${project}/mca-param.conf
>>   and/or  /etc/${project}/${project}-mca-param.conf)
>> 
>> c) prefixing the mca param with the project name in the existing 
>> mca-param.conf
>>  file and therefore following the new MCA variable system naming scheme.
>>  Example:
>>           mca_${project}_${framework}_${component}_${var_name}
>> 
>> The implementation has to be compatible with the current system, that is, 
>> it should work as it does today without any added burden to the user. The
>> suggested approach is to provide an addition to the MCA API (something like
>> mca_base_add_config_file_path ()) to add lookup paths to the MCA system.
>> This way additional files can be picked up for the MCA param parsing if
>> needed.
>> 
>> To wrap it up:
>> 1) Is the motivation clear?
>> 2) Is it possible to implement the desired capability within a
>>   reasonable time and without changing the current behavior?
>> 3) Does it line up with the planning / future capabilities?
>> 4) Which of the above options (A, B, C) would you prefer?
>> 
>> -- 
>> Swen Boehm                                      | Email: bo...@ornl.gov
>> Oak Ridge National Laboratory      | Phone: +1 865-576-6125
>> 
>> 
>> On Apr 26, 2013, at 7:50 PM, Thomas Naughton <naught...@ornl.gov> wrote:
>> 
>>> Hi,
>>> 
>>> Ok, sounds good. We'll check on this next week and get back to you.
>>> 
>>> Thanks,
>>> --tjn
>>> 
>>> _________________________________________________________________________
>>> Thomas Naughton                                      naught...@ornl.gov
>>> Research Associate                                   (865) 576-4184
>>> 
>>> 
>>> On Fri, 26 Apr 2013, Jeff Squyres (jsquyres) wrote:
>>> 
>>>> Email would probably be easiest -- I will need to page in/refresh this 
>>>> area of the code, anyway, so if you guys do the initial homework and 
>>>> submit some ideas, that would probably be easiest (For me).  :-D
>>>> 
>>>> 
>>>> On Apr 26, 2013, at 6:33 PM, Thomas Naughton <naught...@ornl.gov>
>>>> wrote:
>>>> 
>>>>> Hi Jeff,
>>>>> 
>>>>> We don't have one yet but we can code something up and submit a patch.
>>>>> 
>>>>> If useful we could quickly sync up beforehand to ensure we are on the 
>>>>> same page.   Phone or email, whatever would be easiest.
>>>>> 
>>>>> What do you think?
>>>>> --tjn
>>>>> 
>>>>> _________________________________________________________________________
>>>>> Thomas Naughton                                      naught...@ornl.gov
>>>>> Research Associate                                   (865) 576-4184
>>>>> 
>>>>> 
>>>>> On Fri, 26 Apr 2013, Jeff Squyres (jsquyres) wrote:
>>>>> 
>>>>>> I'm not aware of any plans to do this.
>>>>>> 
>>>>>> Do you guys have a patch to submit, perchance?  :-D
>>>>>> 
>>>>>> 
>>>>>> On Apr 22, 2013, at 6:30 PM, Thomas Naughton <naught...@ornl.gov> wrote:
>>>>>> 
>>>>>>> Hi Nathan & Jeff,
>>>>>>> 
>>>>>>> You guys have done some MCA updates lately and we were curious if there 
>>>>>>> are
>>>>>>> any plans or thoughts about an enhancement regarding MCA param files.
>>>>>>> 
>>>>>>> Briefly speaking, we were curious if there were plans for either having
>>>>>>> project specific MCA param files, or having a generic mca param file 
>>>>>>> that
>>>>>>> would use the projects as part of the namespace.  I think an example 
>>>>>>> would
>>>>>>> help clarify.
>>>>>>> 
>>>>>>> We currently change things to have "$HOME/.stci/mca-params.conf".  This 
>>>>>>> is
>>>>>>> pretty much the only remaining modification we have for OPAL after 
>>>>>>> recent
>>>>>>> updates.  If there was a way to have something like
>>>>>>> "$HOME/.${project}/mca-params.conf", or
>>>>>>> "$HOME/.mca/${project}-mca-params.conf", it would remove this remaining 
>>>>>>> customization we do to OPAL.
>>>>>>> 
>>>>>>> This sort of thing seems like it could be a useful if OPAL became
>>>>>>> stand-alone in the future -- it seems like you guys might be moving that
>>>>>>> way?
>>>>>>> 
>>>>>>> We didn't know if you guys had plans for anything related to this 
>>>>>>> and/or if
>>>>>>> you'd be receptive to changes to support something along this line.
>>>>>>> 
>>>>>>> We would be very interested to get your comments/thoughts.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> --tjn
>>>>>>> 
>>>>>>> _________________________________________________________________________
>>>>>>> Thomas Naughton                                      naught...@ornl.gov
>>>>>>> Research Associate                                   (865) 576-4184
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Jeff Squyres
>>>>>> jsquy...@cisco.com
>>>>>> For corporate legal information go to: 
>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Jeff Squyres
>>>> jsquy...@cisco.com
>>>> For corporate legal information go to: 
>>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>> 
>>>> 
>> 
> 
> 
> -- 
> 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


Reply via email to