This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
I think you didn't get the idea. I'm absolutely not volunteering. I'm
just stating that it get into the trunk way to early in a stage where
it shouldn't. And that's starting to become a very common problem in
Open MPI nowadays.
Moreover, as it is supposed to be a generic aggregate file why should
we copy&paste (even 10 lines of code)? It shouldn't be in any of the
components, if it's general then it should go in the base.
On Apr 5, 2007, at 1:25 PM, Josh Hursey wrote:
> Discriminate we did. Not intentionally, but you are correct that it
> is not supported by all the launchers yet.
> We are not removing it, but I don't have the cycles at the moment to
> add the support to all the different launchers. It is about 10 lines
> that need to be added to the launchers, and shouldn't take much time.
> Are you volunteering?
> -- Josh
> On Apr 5, 2007, at 1:10 PM, George Bosilca wrote:
>> I'm coming back on this feature. Whatever it does, it doesn't do it
>> right. If we support a new feature, then at least it should be
>> supported by all launchers (HINT it should go somewhere in the
>> base). As I read the PLS code, only the RSH PLS can have this
>> feature. That's called discrimination !!! Either we support it
>> everywhere, or we completely remove it.
>> On Mar 2, 2007, at 3:58 PM, Jeff Squyres wrote:
>>> On Mar 2, 2007, at 3:37 PM, Josh Hursey wrote:
>>>> Certainly the end user could specify another file to use in
>>>> to the default MCA parameter files (mca_param_files), but then they
>>>> must also specify the other locations that already exist in that
>>>> (e.g., $HOME/.openmpi/mca-params.conf:$SYSCONFDIR/openmpi-mca-
>>>> params.conf). This is a short cut in a sense, so the end user
>>>> have to know all of this uglyness every time they want to run a
>>>> benchmark, or ...
>>> This is the main point of AMCA's: user convenience. Yes, you could
>>> supply 20 MCA params on the command line, or set them in the
>>> environment, or add them to your $HOME/.openmpi .conf file, or
>>> add an
>>> individual file to your MCA param file list, or ... The --amca
>>> is effectively syntactic sugar for adding a .conf file to the MCA
>>> param file list. It seemed a whole lot easier to do:
>>> mpirun --amca my_benchmark_settings.conf ...
>>> foo=`ompi_info --param mca base --parsable | grep
>>> mca_param_files:value | cut -d: -f7-`
>>> mpirun --mca mca_base_path my_benchmark_settings.conf:$foo ...
>>> The intent is that various AMCA files can be introduced and
>>> around the code base (I have one for the openib BTL for
>>> for example -- settings that you wouldn't use in production, but you
>>> would use with netpipe).
>>> Jeff Squyres
>>> Server Virtualization Business Unit
>>> Cisco Systems
>>> devel mailing list
>> devel mailing list
> devel mailing list
- application/pkcs7-signature attachment: smime.p7s