On Jul 18, 2013, at 11:50 AM, George Bosilca <bosilca_at_[hidden]> wrote:
> How is this part of the code validated? It might capitalize on some type of "trust". Unfortunately
I have no such notion.
Not sure what you're asking here.
> I would rather take the path of the "least astonishment", a __consistent__ behavior where we always abide to the configuration files (user level as well as system level). If you want to see every single parameter possibly available to you (based on your rights of course), temporary remove the configuration file. Or we can provide a specific ompi_info option to ignore the configuration files, but not make this the default.
I think MPI applications and ompi_info are different cases.
1. We've definitely had cases of user (and OMPI developer!) confusion over the years where people would run ompi_info and not see their favorite MCA component listed. After a while, they figured out it was because they had an env variable/file limiting which components were used (e.g., OMPI_MCA_btl=sm,tcp,self would silently disable all other BTLs in ompi_info output). This actually seems to be fairly counter-intuitive behavior, if you ask me -- it was done this way as an artifact of the old implementation architecture.
Personally, I think changing ompi_info's behavior to always listing all components is a good idea. Is there a reason to be concerned about the memory footprint and IO traffic of running ompi_info?
What might be a useful addition, however, is in the above example (user has OMPI_MCA_btl=sm,tcp,self in their environment) to somehow mark all other BTL params as "inactive because of OMPI_MCA_BTL env variable value", or something like that.
*** If someone wants this behavior, please propose a specific way to mark prettyprint and parsable ompi_info output.
2. MPI application behavior has not changed -- if you call MPI_Init, we open exactly the same frameworks/components that were opened before. But if you're using a tool (i.e., call the MPI_T init function), then you pay an extra price (potentially more dlopens, more memory usage, etc.). This is the same as it has always been for tools: tools cost something (memory, performance, whatever).
That being said, if you want a different behavior, please propose something specific (e.g., specific new MCA param + value(s) for specific behavior(s)).
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/