Re: [OMPI devel] Recv from MTL module hanging on pml_cm_recv.c:mca_pml_cm_recv()
Caciano, It's a little bit more complex than that. In fact you should never set the req_complete flag to true yourself. Instead you should use ompi_request_complete (defined in ompi/request/request.h) which will set the flag and trigger a condition broadcast or signal for you. This will allow the upper level to be released from the requests condition, and therefore discover that the request is completed. george. On May 8, 2008, at 8:27 PM, Caciano Machado wrote: Hi, I'm finishing the implementation of a MTL module but something went wrong. This module is using PML/cm and the Recv operations are hanging in the ompi_request_wait_completion() call in pml_cm_recv.c:mca_pml_cm_recv(). I think that I must set the variable recvreq->req_base.req_ompi.req_complete somewhere but I don't know exactly where is the right place. When I comment out the ompi_request_wait_completion() call the application messages are delivered correctly with my backend. Regards, Caciano ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel smime.p7s Description: S/MIME cryptographic signature
Re: [OMPI devel] [RFC] mca_base_select()
Thanks very much Josh! Will try it out soon. Josh Hursey wrote: Sorry about that. I didn't test that type of option. It should be working in r18418. Let me know if you see any more issues. -- Josh On May 8, 2008, at 6:04 PM, Pak Lui wrote: I think I have a problem but I am not sure. I used to be able to use the circumflex (^) to switch between the gridengine launcher and the ssh launchers by doing something like this, e.g. -mca plm ^gridengine, to exclude some of the components plm (and also in ras). It doesn't seem like the 'negate' is in mca_base_component anymore. I guess I just have to spell out which component I want explicitly... Josh Hursey wrote: This has been committed in r18381 Please let me know if you have any problems with this commit. Cheers, Josh On May 5, 2008, at 10:41 AM, Josh Hursey wrote: Awesome. The branch is updated to the latest trunk head. I encourage folks to check out this repository and make sure that it builds on their system. A normal build of the branch should be enough to find out if there are any cut-n-paste problems (though I tried to be careful, mistakes do happen). I haven't heard any problems so this is looking like it will come in tomorrow after the teleconf. I'll ask again there to see if there are any voices of concern. Cheers, Josh On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: This all sounds good to me! On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: What: Add mca_base_select() and adjust frameworks & components to use it. Why: Consolidation of code for general goodness. Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca-play When: Code ready now. Documentation ready soon. Timeout: May 6, 2008 (After teleconf) [1 week] Discussion: --- For a number of years a few developers have been talking about creating a MCA base component selection function. For various reasons this was never implemented. Recently I decided to give it a try. A base select function will allow Open MPI to provide completely consistent selection behavior for many of its frameworks (18 of 31 to be exact at the moment). The primary goal of this work is to improving code maintainability through code reuse. Other benefits also result such as a slightly smaller memory footprint. The mca_base_select() function represented the most commonly used logic for component selection: Select the one component with the highest priority and close all of the not selected components. This function can be found at the path below in the branch: opal/mca/base/mca_base_components_select.c To support this I had to formalize a query() function in the mca_base_component_t of the form: int mca_base_query_component_fn(mca_base_module_t **module, int *priority); This function is specified after the open and close component functions in this structure as to allow compatibility with frameworks that do not use the base selection logic. Frameworks that do *not* use this function are *not* effected by this commit. However, every component in the frameworks that use the mca_base_select function must adjust their component query function to fit that specified above. 18 frameworks in Open MPI have been changed. I have updated all of the components in the 18 frameworks available in the trunk on my branch. The effected frameworks are: - OPAL Carto - OPAL crs - OPAL maffinity - OPAL memchecker - OPAL paffinity - ORTE errmgr - ORTE ess - ORTE Filem - ORTE grpcomm - ORTE odls - ORTE pml - ORTE ras - ORTE rmaps - ORTE routed - ORTE snapc - OMPI crcp - OMPI dpm - OMPI pubsub There was a question of the memory footprint change as a result of this commit. I used 'pmap' to determine process memory footprint of a hello world MPI program. Static and Shared build numbers are below along with variations on launching locally and to a single node allocated by SLURM. All of this was on Indiana University's Odin machine. We compare against the trunk (r18276) representing the last SVN sync point of the branch. Process(shared)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 39976K | 36828K | 3148K hello (0) | 229288K | 229268K | 20K hello (1) | 229288K | 229268K | 20K ---+--+-+--- mpirun | 40032K | 37924K | 2108K orted | 34720K | 34660K | 60K hello (0) | 228404K | 228384K | 20K hello (1) | 228404K | 228384K | 20K Process(static)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 21384K | 21372K | 12K hello (0) | 194000K | 193980K | 20K hello (1) | 194000K | 193980K | 20K ---+--+-+--- mpirun | 21384K | 21372K | 12K orted | 21208K | 21196K | 12K hello (0) | 193116K | 193096K | 20K hello (1) | 193116K | 193096K | 20K As you can see there are some small memory footprint improvements on my branch th
[OMPI devel] Recv from MTL module hanging on pml_cm_recv.c:mca_pml_cm_recv()
Hi, I'm finishing the implementation of a MTL module but something went wrong. This module is using PML/cm and the Recv operations are hanging in the ompi_request_wait_completion() call in pml_cm_recv.c:mca_pml_cm_recv(). I think that I must set the variable recvreq->req_base.req_ompi.req_complete somewhere but I don't know exactly where is the right place. When I comment out the ompi_request_wait_completion() call the application messages are delivered correctly with my backend. Regards, Caciano
Re: [OMPI devel] [RFC] mca_base_select()
Sorry about that. I didn't test that type of option. It should be working in r18418. Let me know if you see any more issues. -- Josh On May 8, 2008, at 6:04 PM, Pak Lui wrote: I think I have a problem but I am not sure. I used to be able to use the circumflex (^) to switch between the gridengine launcher and the ssh launchers by doing something like this, e.g. -mca plm ^gridengine, to exclude some of the components plm (and also in ras). It doesn't seem like the 'negate' is in mca_base_component anymore. I guess I just have to spell out which component I want explicitly... Josh Hursey wrote: This has been committed in r18381 Please let me know if you have any problems with this commit. Cheers, Josh On May 5, 2008, at 10:41 AM, Josh Hursey wrote: Awesome. The branch is updated to the latest trunk head. I encourage folks to check out this repository and make sure that it builds on their system. A normal build of the branch should be enough to find out if there are any cut-n-paste problems (though I tried to be careful, mistakes do happen). I haven't heard any problems so this is looking like it will come in tomorrow after the teleconf. I'll ask again there to see if there are any voices of concern. Cheers, Josh On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: This all sounds good to me! On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: What: Add mca_base_select() and adjust frameworks & components to use it. Why: Consolidation of code for general goodness. Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca-play When: Code ready now. Documentation ready soon. Timeout: May 6, 2008 (After teleconf) [1 week] Discussion: --- For a number of years a few developers have been talking about creating a MCA base component selection function. For various reasons this was never implemented. Recently I decided to give it a try. A base select function will allow Open MPI to provide completely consistent selection behavior for many of its frameworks (18 of 31 to be exact at the moment). The primary goal of this work is to improving code maintainability through code reuse. Other benefits also result such as a slightly smaller memory footprint. The mca_base_select() function represented the most commonly used logic for component selection: Select the one component with the highest priority and close all of the not selected components. This function can be found at the path below in the branch: opal/mca/base/mca_base_components_select.c To support this I had to formalize a query() function in the mca_base_component_t of the form: int mca_base_query_component_fn(mca_base_module_t **module, int *priority); This function is specified after the open and close component functions in this structure as to allow compatibility with frameworks that do not use the base selection logic. Frameworks that do *not* use this function are *not* effected by this commit. However, every component in the frameworks that use the mca_base_select function must adjust their component query function to fit that specified above. 18 frameworks in Open MPI have been changed. I have updated all of the components in the 18 frameworks available in the trunk on my branch. The effected frameworks are: - OPAL Carto - OPAL crs - OPAL maffinity - OPAL memchecker - OPAL paffinity - ORTE errmgr - ORTE ess - ORTE Filem - ORTE grpcomm - ORTE odls - ORTE pml - ORTE ras - ORTE rmaps - ORTE routed - ORTE snapc - OMPI crcp - OMPI dpm - OMPI pubsub There was a question of the memory footprint change as a result of this commit. I used 'pmap' to determine process memory footprint of a hello world MPI program. Static and Shared build numbers are below along with variations on launching locally and to a single node allocated by SLURM. All of this was on Indiana University's Odin machine. We compare against the trunk (r18276) representing the last SVN sync point of the branch. Process(shared)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 39976K | 36828K | 3148K hello (0) | 229288K | 229268K | 20K hello (1) | 229288K | 229268K | 20K ---+--+-+--- mpirun | 40032K | 37924K | 2108K orted | 34720K | 34660K | 60K hello (0) | 228404K | 228384K | 20K hello (1) | 228404K | 228384K | 20K Process(static)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 21384K | 21372K | 12K hello (0) | 194000K | 193980K | 20K hello (1) | 194000K | 193980K | 20K ---+--+-+--- mpirun | 21384K | 21372K | 12K orted | 21208K | 21196K | 12K hello (0) | 193116K | 193096K | 20K hello (1) | 193116K | 193096K | 20K As you can see there are some small memory footprint improvements on my branch that result from this work. The size of the
Re: [OMPI devel] "__printf__" attribute
Cool; I've updated the wiki. Thanks! On May 8, 2008, at 6:29 PM, Aurélien Bouteiller wrote: They refer to the parameters of the function. In the example linked, 2 means the fmt is the second argument of the function and 3 is the first variadic arg related to the fmt string. Aurelien Le 8 mai 08 à 18:24, Jeff Squyres a écrit : Rainer -- What do the numeric arguments refer to in the attribute format stuff? The wiki page has only one example, and it doesn't explain what these numbers are: https://svn.open-mpi.org/trac/ompi/wiki/CompilerAttributes Thanks! -- Jeff Squyres Cisco Systems ___ 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 -- Jeff Squyres Cisco Systems
Re: [OMPI devel] "__printf__" attribute
They refer to the parameters of the function. In the example linked, 2 means the fmt is the second argument of the function and 3 is the first variadic arg related to the fmt string. Aurelien Le 8 mai 08 à 18:24, Jeff Squyres a écrit : Rainer -- What do the numeric arguments refer to in the attribute format stuff? The wiki page has only one example, and it doesn't explain what these numbers are: https://svn.open-mpi.org/trac/ompi/wiki/CompilerAttributes Thanks! -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
[OMPI devel] "__printf__" attribute
Rainer -- What do the numeric arguments refer to in the attribute format stuff? The wiki page has only one example, and it doesn't explain what these numbers are: https://svn.open-mpi.org/trac/ompi/wiki/CompilerAttributes Thanks! -- Jeff Squyres Cisco Systems
Re: [OMPI devel] [RFC] mca_base_select()
I think I have a problem but I am not sure. I used to be able to use the circumflex (^) to switch between the gridengine launcher and the ssh launchers by doing something like this, e.g. -mca plm ^gridengine, to exclude some of the components plm (and also in ras). It doesn't seem like the 'negate' is in mca_base_component anymore. I guess I just have to spell out which component I want explicitly... Josh Hursey wrote: This has been committed in r18381 Please let me know if you have any problems with this commit. Cheers, Josh On May 5, 2008, at 10:41 AM, Josh Hursey wrote: Awesome. The branch is updated to the latest trunk head. I encourage folks to check out this repository and make sure that it builds on their system. A normal build of the branch should be enough to find out if there are any cut-n-paste problems (though I tried to be careful, mistakes do happen). I haven't heard any problems so this is looking like it will come in tomorrow after the teleconf. I'll ask again there to see if there are any voices of concern. Cheers, Josh On May 5, 2008, at 9:58 AM, Jeff Squyres wrote: This all sounds good to me! On Apr 29, 2008, at 6:35 PM, Josh Hursey wrote: What: Add mca_base_select() and adjust frameworks & components to use it. Why: Consolidation of code for general goodness. Where: https://svn.open-mpi.org/svn/ompi/tmp-public/jjh-mca-play When: Code ready now. Documentation ready soon. Timeout: May 6, 2008 (After teleconf) [1 week] Discussion: --- For a number of years a few developers have been talking about creating a MCA base component selection function. For various reasons this was never implemented. Recently I decided to give it a try. A base select function will allow Open MPI to provide completely consistent selection behavior for many of its frameworks (18 of 31 to be exact at the moment). The primary goal of this work is to improving code maintainability through code reuse. Other benefits also result such as a slightly smaller memory footprint. The mca_base_select() function represented the most commonly used logic for component selection: Select the one component with the highest priority and close all of the not selected components. This function can be found at the path below in the branch: opal/mca/base/mca_base_components_select.c To support this I had to formalize a query() function in the mca_base_component_t of the form: int mca_base_query_component_fn(mca_base_module_t **module, int *priority); This function is specified after the open and close component functions in this structure as to allow compatibility with frameworks that do not use the base selection logic. Frameworks that do *not* use this function are *not* effected by this commit. However, every component in the frameworks that use the mca_base_select function must adjust their component query function to fit that specified above. 18 frameworks in Open MPI have been changed. I have updated all of the components in the 18 frameworks available in the trunk on my branch. The effected frameworks are: - OPAL Carto - OPAL crs - OPAL maffinity - OPAL memchecker - OPAL paffinity - ORTE errmgr - ORTE ess - ORTE Filem - ORTE grpcomm - ORTE odls - ORTE pml - ORTE ras - ORTE rmaps - ORTE routed - ORTE snapc - OMPI crcp - OMPI dpm - OMPI pubsub There was a question of the memory footprint change as a result of this commit. I used 'pmap' to determine process memory footprint of a hello world MPI program. Static and Shared build numbers are below along with variations on launching locally and to a single node allocated by SLURM. All of this was on Indiana University's Odin machine. We compare against the trunk (r18276) representing the last SVN sync point of the branch. Process(shared)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 39976K | 36828K | 3148K hello (0) | 229288K | 229268K | 20K hello (1) | 229288K | 229268K | 20K ---+--+-+--- mpirun | 40032K | 37924K | 2108K orted | 34720K | 34660K | 60K hello (0) | 228404K | 228384K | 20K hello (1) | 228404K | 228384K | 20K Process(static)| Trunk| Branch | Diff (Improvement) ---+--+-+--- mpirun (orted) | 21384K | 21372K | 12K hello (0) | 194000K | 193980K | 20K hello (1) | 194000K | 193980K | 20K ---+--+-+--- mpirun | 21384K | 21372K | 12K orted | 21208K | 21196K | 12K hello (0) | 193116K | 193096K | 20K hello (1) | 193116K | 193096K | 20K As you can see there are some small memory footprint improvements on my branch that result from this work. The size of the Open MPI project shrinks a bit as well. This commit cuts between 3,500 and 2,000 lines of code (depending on how you count) so about a ~1% code shrink. The branch is stable in all of th
Re: [OMPI devel] [OMPI users] OpenMPI Internals & Static-Analysis.
Hi. The OMPI community should think to come with OpenMPI Internals document. Probably having an Internal document will certainly help developers of OpenMPI. What one has to do - if one is thinking to come with OMPI Internals document to start with? Is there any link or project repository within OMPI to start working on OMPI Internals document. BR
Re: [OMPI devel] [RFC] mca_base_open() NULL
Sounds good. I can probably try to finish the patch in the next couple weeks, but if someone needs it before I get a chance to look at it let me know. Once the implementation is complete, then the RFC will be updated with a termination date for further input. Cheers, Josh On May 8, 2008, at 11:00 AM, Jeff Squyres wrote: On May 8, 2008, at 9:32 AM, Josh Hursey wrote: I think 'all' would be a nice symmetric addition to complement 'none' and then this would allow users to specify the "select best from all available" option on the command line. Ok, if you accept "all" and "none" as friendly ammendments to your RFC, I think I'm done with input there. :-) Any other comments on the RFC? Disallowing the NULL default string I think would have some repercussions throughout the code requiring a change in the way we use MCA parameters. For example, many component selection logics use the NULL value as the current 'select best from all' indicator. Other MCA parameters take the NULL value to indicate that the user did not set any value for this string parameter and thus it can be ignored. Maybe we can try to add a deprecation warning message when this happens to gauge it's frequency. There's no burning need to do this ASAP; let's add this to the list of items to talk about in the tech meeting. Perhaps one of us could do a little prep before the meeting to figure out: - how often NULL is given as a default OMPI MCA string param (probably quite often) -- easy enough to find out by putting a counter/ opal_output in the string registration function - how often NULL is *required* by the logic for one reason or another (probably a little more tricky to count) -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] [RFC] mca_base_open() NULL
On May 8, 2008, at 9:32 AM, Josh Hursey wrote: I think 'all' would be a nice symmetric addition to complement 'none' and then this would allow users to specify the "select best from all available" option on the command line. Ok, if you accept "all" and "none" as friendly ammendments to your RFC, I think I'm done with input there. :-) Any other comments on the RFC? Disallowing the NULL default string I think would have some repercussions throughout the code requiring a change in the way we use MCA parameters. For example, many component selection logics use the NULL value as the current 'select best from all' indicator. Other MCA parameters take the NULL value to indicate that the user did not set any value for this string parameter and thus it can be ignored. Maybe we can try to add a deprecation warning message when this happens to gauge it's frequency. There's no burning need to do this ASAP; let's add this to the list of items to talk about in the tech meeting. Perhaps one of us could do a little prep before the meeting to figure out: - how often NULL is given as a default OMPI MCA string param (probably quite often) -- easy enough to find out by putting a counter/ opal_output in the string registration function - how often NULL is *required* by the logic for one reason or another (probably a little more tricky to count) -- Jeff Squyres Cisco Systems
Re: [OMPI devel] [RFC] mca_base_open() NULL
On May 8, 2008, at 8:15 AM, Jeff Squyres wrote: On May 8, 2008, at 8:06 AM, Josh Hursey wrote: --> If not intended to be used by users (i.e., it's an internal mechanism only), is there a reason why we're not using a zero-length string (e.g., mpirun --mca foo "")? I think a zero length string might get confusing with the empty string. The empty string is taken to mean auto-select from all available components, which currently cannot be specified on the command line as an -mca option. The 0 length string is close and nearly indistinguishable in an (A)MCA file from a NULL string. Ah, right. Should we introduce another keyword, "all"? This would then be symmetric to "none" and could be the default value. An empty string would then be an error. Per the larger issue, I wonder if we should simply disallow NULL default string parameter values. This might simplify a lot of things... I think 'all' would be a nice symmetric addition to complement 'none' and then this would allow users to specify the "select best from all available" option on the command line. Disallowing the NULL default string I think would have some repercussions throughout the code requiring a change in the way we use MCA parameters. For example, many component selection logics use the NULL value as the current 'select best from all' indicator. Other MCA parameters take the NULL value to indicate that the user did not set any value for this string parameter and thus it can be ignored. Maybe we can try to add a deprecation warning message when this happens to gauge it's frequency. -- Josh -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] [RFC] mca_base_open() NULL
On May 8, 2008, at 8:06 AM, Josh Hursey wrote: --> If not intended to be used by users (i.e., it's an internal mechanism only), is there a reason why we're not using a zero-length string (e.g., mpirun --mca foo "")? I think a zero length string might get confusing with the empty string. The empty string is taken to mean auto-select from all available components, which currently cannot be specified on the command line as an -mca option. The 0 length string is close and nearly indistinguishable in an (A)MCA file from a NULL string. Ah, right. Should we introduce another keyword, "all"? This would then be symmetric to "none" and could be the default value. An empty string would then be an error. Per the larger issue, I wonder if we should simply disallow NULL default string parameter values. This might simplify a lot of things... -- Jeff Squyres Cisco Systems
Re: [OMPI devel] [RFC] mca_base_open() NULL
On May 8, 2008, at 7:50 AM, Jeff Squyres wrote: FWIW: - I think "none" is a slightly better word than "null" for this value; "none" implies that you don't open anything, whereas "null" could be a specific component (as it is/was in some frameworks). Calling it 'none' sounds fine to me. - Whatever word we decide on will need to become a reserved component name (i.e., no components will be able to use that as their name). We should adjust autogen.sh and friends to ensure that no component has this name (not difficult -- just make autogen.sh abort if it finds a component of this name). Good idea. - Is this value supposed to be accessible/usable by users, or is it meant to only be used internally? I would say it should be used internally. But I don't know what use case Ralph was thinking of with this. There is something to be said for being able to add such an option to the .openmpi/mca-params.conf file while testing or to an AMCA file for a particular configuration. So maybe we should expose it. It may able be useful for debugging problems encountered in the wild. --> If intended to be used by users, I marginally prefer a single, lower case, simple word (e.g., "none") vs. a caps word -- it's easier to type and is consistent with our other values. I recognize that we don't want users to use the value by accident, and making it all caps makes it stand out, but I think the consistency issues are more important. Keeping it case-consistent with other components is probably a good thing. --> If not intended to be used by users (i.e., it's an internal mechanism only), is there a reason why we're not using a zero-length string (e.g., mpirun --mca foo "")? I think a zero length string might get confusing with the empty string. The empty string is taken to mean auto-select from all available components, which currently cannot be specified on the command line as an -mca option. The 0 length string is close and nearly indistinguishable in an (A)MCA file from a NULL string. -- Josh On May 6, 2008, at 2:09 PM, Josh Hursey wrote: What: Add a MCA-NULL option to open no components in mca_base_open() Why: Sometimes we do not want to open or select any components of a framework. Where: patch attached for current trunk. When: Needs further discussion. Timeout: Unknown. [May 13, 2008 (After teleconf)?] Short Version: -- This RFC is intended to continue discussion on the thread started here: http://www.open-mpi.org/community/lists/devel/2008/05/3793.php Discussion should occur on list, but maybe try to come to some settlement on this RFC in the next week or two. Longer Version: --- Currently there is no way to express to the MCA system that absolutely no components of a framework are needed and therefore nothing should be opened. The addition of a sentinel value is needed to explicitly express this intention. It was suggested that if a 'MCA-NULL' value is passed as an argument for a framework then this should be taken to indicate such an intention. ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] [RFC] mca_base_open() NULL
FWIW: - I think "none" is a slightly better word than "null" for this value; "none" implies that you don't open anything, whereas "null" could be a specific component (as it is/was in some frameworks). - Whatever word we decide on will need to become a reserved component name (i.e., no components will be able to use that as their name). We should adjust autogen.sh and friends to ensure that no component has this name (not difficult -- just make autogen.sh abort if it finds a component of this name). - Is this value supposed to be accessible/usable by users, or is it meant to only be used internally? --> If intended to be used by users, I marginally prefer a single, lower case, simple word (e.g., "none") vs. a caps word -- it's easier to type and is consistent with our other values. I recognize that we don't want users to use the value by accident, and making it all caps makes it stand out, but I think the consistency issues are more important. --> If not intended to be used by users (i.e., it's an internal mechanism only), is there a reason why we're not using a zero-length string (e.g., mpirun --mca foo "")? On May 6, 2008, at 2:09 PM, Josh Hursey wrote: What: Add a MCA-NULL option to open no components in mca_base_open() Why: Sometimes we do not want to open or select any components of a framework. Where: patch attached for current trunk. When: Needs further discussion. Timeout: Unknown. [May 13, 2008 (After teleconf)?] Short Version: -- This RFC is intended to continue discussion on the thread started here: http://www.open-mpi.org/community/lists/devel/2008/05/3793.php Discussion should occur on list, but maybe try to come to some settlement on this RFC in the next week or two. Longer Version: --- Currently there is no way to express to the MCA system that absolutely no components of a framework are needed and therefore nothing should be opened. The addition of a sentinel value is needed to explicitly express this intention. It was suggested that if a 'MCA-NULL' value is passed as an argument for a framework then this should be taken to indicate such an intention. ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems
Re: [OMPI devel] [OMPI users] OpenMPI Internals & Static-Analysis.
On May 8, 2008, at 5:06 AM, Mukesh K Srivastava wrote: Hi. Greetings! There probably isn't much need to CC both lists; this question is probably more suited for the devel list. I'm following up to both lists so that the answer is archived on the web properly, but if there's any followups to this, let's just use the devel list. Thanks! Out of curiosity, was looking to know - Query#1: Does OpenMPI has any document related with OpenMPI Internals? Unfortunately not. :-( Query#2: Does any slides talks of OpenMPI internals, If yes, any links for the same? We have a few papers that talk about the generalities of our internals, but nothing down to the code level details. FWIW, various parts of OMPI are more documented than others in code comments (e.g., OPAL is fairly well documented in header files, etc.). Most framework header files (e.g., /mca//.h) describe the interfaces for their modules and components at least reasonably well. The devel list is probably your best bet for asking questions, etc. Query#3: Do any Static-Analysis open-source tools are available for analyzing OpenMPI? Probably, Coverity "Prevent" does provide static- analysis but does it work for OpenMPI too? Yes, Coverity is actually an Open MPI project partner. They analyze the OMPI nightly tarballs (starting with the upcoming v1.3 series -- we didn't use Coverity for the v1.2 series). -- Jeff Squyres Cisco Systems
[OMPI devel] OpenMPI Internals & Static-Analysis.
Hi. Out of curiosity, was looking to know - Query#1: Does OpenMPI has any document related with OpenMPI Internals? Query#2: Does any slides talks of OpenMPI internals, If yes, any links for the same? Query#3: Do any Static-Analysis open-source tools are available for analyzing OpenMPI? Probably, Coverity "Prevent" does provide static-analysis but does it work for OpenMPI too? Any links or reference is appreciated. BR
