[hwloc-devel] Create success (hwloc r1.5.3rc1r5595)

[MPI Team]

Creating nightly hwloc snapshot SVN tarball was a success.

Snapshot:   hwloc 1.5.3rc1r5595
Start time: Tue May  7 21:14:17 EDT 2013
End time:   Tue May  7 21:18:21 EDT 2013

Your friendly daemon,
Cyrador

[hwloc-devel] Create success (hwloc r1.7.1rc1r5593)

[MPI Team]

Creating nightly hwloc snapshot SVN tarball was a success.

Snapshot:   hwloc 1.7.1rc1r5593
Start time: Tue May  7 21:05:39 EDT 2013
End time:   Tue May  7 21:09:53 EDT 2013

Your friendly daemon,
Cyrador

[hwloc-devel] Create success (hwloc r1.8a1r5606)

[MPI Team]

Creating nightly hwloc snapshot SVN tarball was a success.

Snapshot:   hwloc 1.8a1r5606
Start time: Tue May  7 21:01:01 EDT 2013
End time:   Tue May  7 21:05:39 EDT 2013

Your friendly daemon,
Cyrador

Re: [hwloc-devel] hwloc embedding vs libltdl

[Jeff Squyres (jsquyres)]

How's this patch?

The only question I have is: how do we figure out what libraries to put in the 
.pc file in the --disable-shared --enable-static case?


On May 7, 2013, at 8:24 PM, Samuel Thibault  wrote:

> Jeff Squyres (jsquyres), le Wed 08 May 2013 02:21:02 +0200, a écrit :
>> On May 7, 2013, at 6:25 PM, Brice Goglin  wrote:
>> 
>>> I don't have anything against this. What was the reason for not using
>>> the default/system libltdl in OMPI? libtool was buggy when you started
>>> using it?
>> 
>> 
>> I neglected to answer this.
>> 
>> Yes, plus libltdl grew new functionality that we needed (global/local symbol 
>> visibility).
>> 
>> We might be getting to the point soon where we can rely on the installed 
>> libltdl to be new enough everywhere, but we haven't had that conversation.
> 
> We could already check that the installed version is new enough for our
> needs.
> 
> Samuel
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/


no-embed-libltdl.diff
Description: no-embed-libltdl.diff

Re: [hwloc-devel] hwloc embedding vs libltdl

[Samuel Thibault]

Jeff Squyres (jsquyres), le Wed 08 May 2013 02:21:02 +0200, a écrit :
> On May 7, 2013, at 6:25 PM, Brice Goglin  wrote:
> 
> > I don't have anything against this. What was the reason for not using
> > the default/system libltdl in OMPI? libtool was buggy when you started
> > using it?
> 
> 
> I neglected to answer this.
> 
> Yes, plus libltdl grew new functionality that we needed (global/local symbol 
> visibility).
> 
> We might be getting to the point soon where we can rely on the installed 
> libltdl to be new enough everywhere, but we haven't had that conversation.

We could already check that the installed version is new enough for our
needs.

Samuel

Re: [hwloc-devel] hwloc embedding vs libltdl

[Jeff Squyres (jsquyres)]

Er... here's the patch I forgot to attach.  :-)



On May 7, 2013, at 6:00 PM, "Jeff Squyres (jsquyres)"  
wrote:

> Sorry for the high latency reply.
>
> I thought about this quite a bit today.  Here's a thinking-out-of-the-box 
> question: should we just use the default/system installed libltdl instead of 
> embedding?  If we don't embed, many of these problems go away, right?  I.e., 
> we can still have the same options for plugins: non-default, but available if 
> you ask for it *and* there's a system-level libltdl available.
>
> FWIW: I see RHEL 6.x uses libtool/libltdl 2.2.6.  Do we:
>
> a) care about supporting plugins by default on distros with older ltdl 
> versions?
> b) use any functionality beyond libltdl 2.2.6?  (or some other 
> older/benchmark distro ltdl version that we care about supporting)
>
> Attached is a patch that does a few minor things:
>
> - avoid the use of AM_CONDITIONAL for the libltdl subdir
> - ensure to have libtool avoid setting up Fortran and C++ (a trick we learned 
> from MPICH :-) )
> - disallow embedded mode and plugins (per our phone discussion the other day)
> - reorder the plugins support AC_MSG_RESULT to come before any WARN/ERROR 
> messages
>
>
> On Apr 30, 2013, at 5:30 AM, Brice Goglin  wrote:
>
>> Jeff,
>>
>> I've been working on making hwloc v1.7 pass our tests/embedded scripts
>> in the last days. I fixed some minor issues but here's the remaining
>> (big) one.
>>
>> First problem is that we need the AM_CONDITIONAL for HWLOC_LTDL_INCLUDED
>> to be executed when embedded. I can fix this by moving into
>> HWLOC_DO_AM_CONDITIONAL. But...
>>
>> We conditionally enable SUBDIRS=libltdl (in src/Makefile.am) when
>> plugins are enabled and the internal ltdl is used. Assuming embedders
>> don't want hwloc plugins, this builds fine since we don't enter libltdl
>> during "make", and we can avoid the (ugly) ltdl configuration entirely
>> [1]. But "make distclean" still enters libltdl unconditionally, and it
>> fails if LTDL wasn't configured because the Makefile is missing.
>>
>> For the record, you had a similar issue with doc/tests/tools where you
>> don't even have a Makefile.am in these directories in OMPI. You fixed it
>> by doing DIST_SUBDIRS=$(SUBDIRS). It means that distclean doesn't enter
>> those directories at all. But it also means that you don't get
>> doc/tests/tools in make dist when embedded is enabled. We don't build
>> hwloc tarballs in embedded mode so that's fine. Using the same idea for
>> my issue would require to build hwloc tarballs with plugins enabled and
>> ltld included (both non default), I don't thing we should to this way.
>>
>> So we need a way to have src/libltdl stay in DIST_SUBDIRS by default, go
>> in SUBDIRS when needed, and disappear totally when embedded. So here's
>> the only solution I finally found: hwloc configure.ac sets a shell
>> variable to yes, and a new AM_CONDITIONAL adds src/libltdl to
>> DIST_SUBDIRS only when this variable is "yes".
>> This still causes hwloc tarballs to contain libltdl (because hwloc
>> configure.ac sets the variable to yes). It's still enabled only when the
>> system doesn't have libltdl installed or --with-included-ltdl is given,
>> as previously. And embedders totally ignore src/libltdl, including in
>> distclean, because they don't set the variable to yes.
>>
>> If an embedder ever wants to use hwloc plugins, he will have to
>> duplicate what the hwloc configure.ac does [1], and it can still link
>> with another libltdl if needed (to be tested).
>>
>> Patch attached, on top of trunk. Note that you may need these additional
>> commits if you or Pavan want to test things [2]
>>
>> Let me know what you think because you have the same problem as Pavan
>> when OMPI switches to hwloc v1.6+
>>
>> Brice
>>
>>
>>
>>
>> [1] Enabling ltdl requires some code like below:configure.ac
>> AM_PROG_LIBTOOL([dlopen win32-dll])
>> LT_LANG([C])
>> # Here's what we need to configure ltdl properly
>> LT_CONFIG_LTDL_DIR([src/libltdl])
>> LTDL_INIT([recursive convenience])
>> AC_CONFIG_FILES([src/libltdl/Makefile])
>> # Tell src/Makefile.am that things were configured under src/libltdl/
>> hwloc_mayenter_src_libltdl=yes
>>
>> libtool doesn't seem to like having it in a HWLOC_SETUP_LTDL macro
>> outside of the main, and I think we have to let embedders call
>> AM_PROG_LIBTOOL() directly in case they need other options.
>>
>> There's also a hack below these lines that is specific to the
>> "recursive" mode, but we may switch to "subproject" mode  (hwloc
>> configure explicitly calls libltdl configure) at some point if libtool
>> doesn't fix the issue.
>>
>> [2]
>> https://svn.open-mpi.org/trac/hwloc/changeset/5563
>> https://svn.open-mpi.org/trac/hwloc/changeset/5562
>>
>> 
>
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
>
> ___
> 

Re: [hwloc-devel] hwloc embedding vs libltdl

[Jeff Squyres (jsquyres)]

Sorry for the high latency reply.

I thought about this quite a bit today.  Here's a thinking-out-of-the-box 
question: should we just use the default/system installed libltdl instead of 
embedding?  If we don't embed, many of these problems go away, right?  I.e., we 
can still have the same options for plugins: non-default, but available if you 
ask for it *and* there's a system-level libltdl available.

FWIW: I see RHEL 6.x uses libtool/libltdl 2.2.6.  Do we:

a) care about supporting plugins by default on distros with older ltdl versions?
b) use any functionality beyond libltdl 2.2.6?  (or some other older/benchmark 
distro ltdl version that we care about supporting)

Attached is a patch that does a few minor things:

- avoid the use of AM_CONDITIONAL for the libltdl subdir
- ensure to have libtool avoid setting up Fortran and C++ (a trick we learned 
from MPICH :-) )
- disallow embedded mode and plugins (per our phone discussion the other day)
- reorder the plugins support AC_MSG_RESULT to come before any WARN/ERROR 
messages


On Apr 30, 2013, at 5:30 AM, Brice Goglin  wrote:

> Jeff,
> 
> I've been working on making hwloc v1.7 pass our tests/embedded scripts
> in the last days. I fixed some minor issues but here's the remaining
> (big) one.
> 
> First problem is that we need the AM_CONDITIONAL for HWLOC_LTDL_INCLUDED
> to be executed when embedded. I can fix this by moving into
> HWLOC_DO_AM_CONDITIONAL. But...
> 
> We conditionally enable SUBDIRS=libltdl (in src/Makefile.am) when
> plugins are enabled and the internal ltdl is used. Assuming embedders
> don't want hwloc plugins, this builds fine since we don't enter libltdl
> during "make", and we can avoid the (ugly) ltdl configuration entirely
> [1]. But "make distclean" still enters libltdl unconditionally, and it
> fails if LTDL wasn't configured because the Makefile is missing.
> 
> For the record, you had a similar issue with doc/tests/tools where you
> don't even have a Makefile.am in these directories in OMPI. You fixed it
> by doing DIST_SUBDIRS=$(SUBDIRS). It means that distclean doesn't enter
> those directories at all. But it also means that you don't get
> doc/tests/tools in make dist when embedded is enabled. We don't build
> hwloc tarballs in embedded mode so that's fine. Using the same idea for
> my issue would require to build hwloc tarballs with plugins enabled and
> ltld included (both non default), I don't thing we should to this way.
> 
> So we need a way to have src/libltdl stay in DIST_SUBDIRS by default, go
> in SUBDIRS when needed, and disappear totally when embedded. So here's
> the only solution I finally found: hwloc configure.ac sets a shell
> variable to yes, and a new AM_CONDITIONAL adds src/libltdl to
> DIST_SUBDIRS only when this variable is "yes".
> This still causes hwloc tarballs to contain libltdl (because hwloc
> configure.ac sets the variable to yes). It's still enabled only when the
> system doesn't have libltdl installed or --with-included-ltdl is given,
> as previously. And embedders totally ignore src/libltdl, including in
> distclean, because they don't set the variable to yes.
> 
> If an embedder ever wants to use hwloc plugins, he will have to
> duplicate what the hwloc configure.ac does [1], and it can still link
> with another libltdl if needed (to be tested).
> 
> Patch attached, on top of trunk. Note that you may need these additional
> commits if you or Pavan want to test things [2]
> 
> Let me know what you think because you have the same problem as Pavan
> when OMPI switches to hwloc v1.6+
> 
> Brice
> 
> 
> 
> 
> [1] Enabling ltdl requires some code like below:configure.ac
> AM_PROG_LIBTOOL([dlopen win32-dll])
> LT_LANG([C])
> # Here's what we need to configure ltdl properly
> LT_CONFIG_LTDL_DIR([src/libltdl])
> LTDL_INIT([recursive convenience])
> AC_CONFIG_FILES([src/libltdl/Makefile])
> # Tell src/Makefile.am that things were configured under src/libltdl/
> hwloc_mayenter_src_libltdl=yes
> 
> libtool doesn't seem to like having it in a HWLOC_SETUP_LTDL macro
> outside of the main, and I think we have to let embedders call
> AM_PROG_LIBTOOL() directly in case they need other options.
> 
> There's also a hack below these lines that is specific to the
> "recursive" mode, but we may switch to "subproject" mode  (hwloc
> configure explicitly calls libltdl configure) at some point if libtool
> doesn't fix the issue.
> 
> [2]
> https://svn.open-mpi.org/trac/hwloc/changeset/5563
> https://svn.open-mpi.org/trac/hwloc/changeset/5562
> 
> 


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] [OMPI svn] svn:open-mpi r28456 - trunk

[Ralph Castain]

On May 7, 2013, at 11:34 AM, Thomas Naughton  wrote:

> Hi,
> 
> Briefly, I'm Thomas.  I work at ORNL.  I changed autogen.pl on my
> first commit to OMPI trunk. (Insert rookie joke here.  :-D)

Welcome!

> 
> The changes in r28456 for autogen.pl were pretty basic/minor.  I
> apologize for not sending a follow-up email to devel mailing list
> outlining the changes -- poor netiquette on my part. :-/
> 
> There were four changes included in the patch.  They related
> mainly to the recent changes for MCA frameworks.  I'll give a little
> more description below.
> 
> Ralph, I also included your feedback and a response for #2.  Let me
> know if this makes sense as I think it provides the "right" behavior
> but want to double check.  Thanks.
> 
> 
>> 1) Add ifdef guard to project's autogenerated "frameworks.h" header
>>file, e.g., "opal/inlude/opal/frameworks.h" would have
>>"OPAL_FRAMEWORKS_H".
> 
> This one simply adds and ifdef to top of auto-generated file, so if code
> includes the "framework.h" file you avoid multiple includes of same file.
> This is generic to the given project so the "opal/" project would generate
> something like:
> 
>  $ cat opal/include/opal/frameworks.h
>  /*
>   * This file is autogenerated by autogen.pl. Do not edit this file by hand.
>   */
>  #ifndef OPAL_FRAMEWORKS_H
>  #define OPAL_FRAMEWORKS_H
> 
>  #include 
> 
>  extern mca_base_framework_t opal_backtrace_base_framework;
> 
> ..
> 
>  #endif /* OPAL_FRAMEWORKS_H */
> 
> This would also be done for "ompi/" and "orte/" project directories.
> 

No issues from anyone that I heard.

> 
> 
> 
>> 2) Avoid adding "ignored" frameworks to the autogenerated "frameworks.h"
>>header file.
> 
> This simply applies the same ignored() function that is used elsewhere in
> the autogen.pl script for omitting "ignored" MCA directories from the
> processing.  This just picks up the ".ompi_ignore" (and/or ".ompi_unignore) 
> files.   The intent being that if you ignore a component (subdir) that will
> be removed from the list, but you could also remove an entire framework if
> you put the ignore file in the top-level of the framework.

That is new - I would suggest not doing that as it behaves differently than you 
might expect. The .ompi_ignore in a component prevents that component from 
building at all, so it won't ever be opened etc. However, the framework *must* 
build the base code no matter what - and that means the framework will be 
opened, selected, and closed at the minimum.

I would prefer we keep ompi_ignore cleanly defined. You can ignore all 
components by simply putting --enable-mca-no-build= on your 
configure line.

> 
> The intent being that if for whatever reason you ignore a framework in the
> "${project}/mca/" space, you will not have it automatically show up in the
> project's "frameworks.h" file.
> 
> On Tue, 7 May 2013, Ralph Castain wrote:
> 
>>> We use the frameworks.h file to "discover" the frameworks in
>>> ompi_info.  Even if no components are built for that framework,
>>> there still are MCA params relating to the base of that framework.
>>> Sounds silly, I know - but there may be reasons to access those
>>> params - e.g., to set verbosity to verify that no components are
>>> being selected.
>>> 
>>> I think we need those frameworks to be listed...
> 
> 
> Ok, I didn't realize the 'ompi_info' aspect.  Good to know.
> However, I think honouring the ignore behavior is good in this case
> b/c if you drop an ignore file in a framework, you won't get any
> other autogen touches (i.e., no Makefile's are autogenerated).  So
> it seems that having no Makefiles but including the framework in the
> "framework.h" would break regardless.  Again, this is more of a
> safety guard.
> 
> 

Actually, I disagree. As stated above, the framework will *always* build the 
base code and be opened, selected, and closed - so you at least need access to 
the verbosity parameter so you can verify those operations. Keeping it in 
ompi_info is of value.

> 
> 
>> 3) Avoid adding non-MCA projects to the autogenerated
>> 'mca_project_list', which maintains existing support for "projects" with new 
>> MCA framework enhancements.  Moves this down to mca_run_global().
> 
> 
> This was just a bit of shifting code and didn't sound like there was
> any discussion on this point.  This is a "do no harm" factor to
> support pre-existing functionality.  The gist is that if you have a
> "project" in the build directory that doesn't have an MCA directory 
> structure, just avoid adding it to the list of MCA projects.

No objections

> 
> 
> 
>> 4) Add small loop at end to add projects with a "config/" subdir
>>   to the list of includes for 'autoreconf'.
> 
> 
> This again is a "do no harm" factor to support pre-exising
> functionality.  If you have a "${project}/config/" directory.  This
> appends  the "-I ${project}/config/" to the autoreconf list.
> If you do not have a "${project}/config/" dir, there is no change.

Re: [OMPI devel] June OMPI developer's meeting

[Larry Baker]

On 6 May 2013, at 11:14 AM, Jeff Squyres (jsquyres) wrote:

> We typically do something informally scheduled on the day of, or somesuch 
> (e.g., around 4pm people start wondering aloud what we should do for dinner 
> :-) ).  But if there is interest for others to attend, we can probably set up 
> something ahead of time.


This option will work best for me.  All I need is an e-mail notice of where and 
when within 30 minutes or so of the reservation time (depending on the traffic 
on 101 :) ).

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov

Re: [OMPI devel] Q: project based MCA param files

[Jeff Squyres (jsquyres)]

On May 7, 2013, at 2:44 PM, Thomas Naughton  wrote:

> Ok, looks like this may just do the trick.  We briefly discussed this today
> and probably can change our use case to make use of this mechanism instead
> and avoid any further enhancments.
> 
> Question: If you do a setenv for this MCA param, does that extend the
>   default search path?  Or does it replace/override the default?

It replaces/overrides.

You don't have to do this via setenv-- you should be able to do it 
programatically, too.

> Thanks Jeff for forwarding info to devel list to get broader feedback, and
> to Ralph for providing the suggestion.
> 
> --tjn
> 
> _
>  Thomas Naughton  naught...@ornl.gov
>  Research Associate   (865) 576-4184
> 
> 
> On Tue, 7 May 2013, Ralph Castain wrote:
> 
>> 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, 
>> _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)  
>> 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" 
 Subject: Re: Q: project based MCA param files
 Date: May 3, 2013 5:03:43 PM EDT
 To: "Jeff Squyres (jsquyres)" 
 Cc: Nathan Hjelm , "Vallee, Geoffroy R." 
 , "Naughton III, Thomas J." 
 
 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  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 

Re: [OMPI devel] Q: project based MCA param files

[Thomas Naughton]

Hi,

Ok, looks like this may just do the trick.  We briefly discussed this today
and probably can change our use case to make use of this mechanism instead
and avoid any further enhancments.

 Question: If you do a setenv for this MCA param, does that extend the
   default search path?  Or does it replace/override the default?

Thanks Jeff for forwarding info to devel list to get broader feedback, and
to Ralph for providing the suggestion.

--tjn

 _
  Thomas Naughton  naught...@ornl.gov
  Research Associate   (865) 576-4184


On Tue, 7 May 2013, Ralph Castain wrote:


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, 
_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)  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" 
Subject: Re: Q: project based MCA param files
Date: May 3, 2013 5:03:43 PM EDT
To: "Jeff Squyres (jsquyres)" 
Cc: Nathan Hjelm , "Vallee, Geoffroy R." , "Naughton 
III, Thomas J." 

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  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 
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

Re: [OMPI devel] [OMPI bugs] [Open MPI] #3593: btl_openib: change SRQ defaults

[Joshua Ladd]

Please see below.

Josh

-Original Message-
From: bugs-boun...@open-mpi.org [mailto:bugs-boun...@open-mpi.org] On Behalf Of 
Open MPI
Sent: Thursday, May 02, 2013 9:12 AM
Cc: b...@open-mpi.org
Subject: [OMPI bugs] [Open MPI] #3593: btl_openib: change SRQ defaults

#3593: btl_openib: change SRQ defaults
-+
Reporter:  amikheev  |  Owner:
Type:  defect| Status:  new
Priority:  major |  Milestone:  Open MPI 1.6.5
 Version:  trunk |   Keywords:
-+
 Apply r28440 and r28441 to 1.6 branch

 reviewed by miked

-- 
Ticket URL: 
Open MPI 

___
bugs mailing list
b...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/bugs

Re: [OMPI devel] [OMPI svn] svn:open-mpi r28456 - trunk

[Thomas Naughton]

Hi,

Briefly, I'm Thomas.  I work at ORNL.  I changed autogen.pl on my
first commit to OMPI trunk. (Insert rookie joke here.  :-D)

The changes in r28456 for autogen.pl were pretty basic/minor.  I
apologize for not sending a follow-up email to devel mailing list
outlining the changes -- poor netiquette on my part. :-/

There were four changes included in the patch.  They related
mainly to the recent changes for MCA frameworks.  I'll give a little
more description below.

Ralph, I also included your feedback and a response for #2.  Let me
know if this makes sense as I think it provides the "right" behavior
but want to double check.  Thanks.



 1) Add ifdef guard to project's autogenerated "frameworks.h" header
file, e.g., "opal/inlude/opal/frameworks.h" would have
"OPAL_FRAMEWORKS_H".


This one simply adds and ifdef to top of auto-generated file, so if code
includes the "framework.h" file you avoid multiple includes of same file.
This is generic to the given project so the "opal/" project would generate
something like:

  $ cat opal/include/opal/frameworks.h
  /*
   * This file is autogenerated by autogen.pl. Do not edit this file by hand.
   */
  #ifndef OPAL_FRAMEWORKS_H
  #define OPAL_FRAMEWORKS_H

  #include 

  extern mca_base_framework_t opal_backtrace_base_framework;

 ..

  #endif /* OPAL_FRAMEWORKS_H */

This would also be done for "ompi/" and "orte/" project directories.





 2) Avoid adding "ignored" frameworks to the autogenerated "frameworks.h"
header file.


This simply applies the same ignored() function that is used elsewhere in
the autogen.pl script for omitting "ignored" MCA directories from the
processing.  This just picks up the ".ompi_ignore" (and/or ".ompi_unignore) 
files.   The intent being that if you ignore a component (subdir) that will

be removed from the list, but you could also remove an entire framework if
you put the ignore file in the top-level of the framework.

The intent being that if for whatever reason you ignore a framework in the
"${project}/mca/" space, you will not have it automatically show up in the
project's "frameworks.h" file.

On Tue, 7 May 2013, Ralph Castain wrote:


We use the frameworks.h file to "discover" the frameworks in
ompi_info.  Even if no components are built for that framework,
there still are MCA params relating to the base of that framework.
Sounds silly, I know - but there may be reasons to access those
params - e.g., to set verbosity to verify that no components are
being selected.

I think we need those frameworks to be listed...



Ok, I didn't realize the 'ompi_info' aspect.  Good to know.
However, I think honouring the ignore behavior is good in this case
b/c if you drop an ignore file in a framework, you won't get any
other autogen touches (i.e., no Makefile's are autogenerated).  So
it seems that having no Makefiles but including the framework in the
"framework.h" would break regardless.  Again, this is more of a
safety guard.





3) Avoid adding non-MCA projects to the autogenerated
'mca_project_list', which maintains existing support for "projects" 
with new MCA framework enhancements.  Moves this down to mca_run_global().



This was just a bit of shifting code and didn't sound like there was
any discussion on this point.  This is a "do no harm" factor to
support pre-existing functionality.  The gist is that if you have a
"project" in the build directory that doesn't have an MCA directory 
structure, just avoid adding it to the list of MCA projects.





4) Add small loop at end to add projects with a "config/" subdir
   to the list of includes for 'autoreconf'.



This again is a "do no harm" factor to support pre-exising
functionality.  If you have a "${project}/config/" directory.  This
appends  the "-I ${project}/config/" to the autoreconf list.
If you do not have a "${project}/config/" dir, there is no change.


Again, I hope that gives more context/description to the changes
included in the autogen.pl patch.  In the future, I'll try to do
a better job of sending a heads up to the devel list.

Thanks,
--tjn

 _
  Thomas Naughton  naught...@ornl.gov
  Research Associate   (865) 576-4184


On Tue, 7 May 2013, Ralph Castain wrote:


Crud - it just struck me that you don't want to do one thing in that patch.


+ Avoid adding "ignored" frameworks to the autogenerated "frameworks.h"
 header file.



We use the frameworks.h file to "discover" the frameworks in ompi_info. Even if 
no components are built for that framework, there still are MCA params relating to the 
base of that framework. Sounds silly, I know - but there may be reasons to access those 
params - e.g., to set verbosity to verify that no components are being selected.

I think we need those frameworks to be listed...


On May 7, 2013, at 6:49 AM, Ralph Castain  wrote:



On May 7, 2013, 

Re: [hwloc-devel] RPATH issues when building in Fedora 18

[Jiri Hladky]

Thanks a lot for all the feedback !!!

I went with
autoreconf --force --install

which solved a problem.

@Jeff: the versions of your quadtuple looks good to me! I'm using the same
with the exception of automake (1.12.2 which is even older than yours).

I have now successfully created rpm for hwloc 1.7 for Fedora.

Jirka

On Wed, Apr 24, 2013 at 2:52 PM, Jeff Squyres (jsquyres)  wrote:

> I'm a little late to this thread, but I just changed the build machine to
> build hwloc trunk tarballs with the same versions of Autotools as the v1.7
> tarballs:
>
> AC 2.69
> AM 1.13.1
> LT 2.4.2
> GM4 1.4.16
>
> Let me know if that's good.  If not, I can install any quadtuple (use that
> in a sentence today) of versions that we need.
>
>
>
> On Apr 24, 2013, at 3:48 AM, Brice Goglin  wrote:
>
> > Le 24/04/2013 08:05, Paul Hargrove a écrit :
> >>
> >> Ok, thanks. So our configure indeed generates libtool script that
> >> depends on where the tarball was generated. That's a bit disturbing.
> >>
> >>
> >> It is not quite as you describe because I was talking about Fedora's
> libtool.m4 doing the hardcoding.
> >> The libtool.m4 logic that is distributed with hwloc *tries* to perform
> a configure probe to determine the dynamic lib search path.
> >> Unfortunately, that probe isn't smart enough to get the right answer on
> all Linux distros.
> >> So, the libtool.m4 from Fedora is the one I see hardcoding the correct
> answer.
> >> Again: libtool in the official tarball of hwloc-1.7 does NOT do
> something as horrible as hardcode the wrong answer from the distro where
> one built the tarball (but it probably would it you built the tarball on
> Fedora).
> >
> > Well, it's the same idea in the end. The libtool.m4 in the hwloc tarball
> is placed there by autoreconf, so it comes from the Debian machine where I
> generate the tarballs. I could generate official tarballs on Fedora to work
> around the issue (some nightly builds are generated this way, but not the
> official ones from the website (RHEL4 iirc).
> >
> >> It appears somebody has been bugging the libtool developers about this
> since June 2010:
> >>
> http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00141.html
> >
> > That "somebody" is the person who opened this hwloc thread yesterday :)
> >
> >> In my testing on Fedora 17, the patch below applied to hwloc-1.7
> produces an accurate sys_lib_dlsearch_path_spec
> >
> > It's crazy that this hasn't been resolved earlier. Many projects may
> have the same problem. Maybe many of them ignore it because they build
> their tarballs on distros with a patched libtool.
> >
> > Anyway, we can't easily patch hwloc's libtool.m4 since we'd have to do
> that during autogen (after libtool.m4 gets copied), and the patch may fail
> against some versions of libtool. We could patch during the release tarball
> generation since we enforce the libtool version there, but I still don't
> fully like the idea.
> >
> >
> > Let's see if Jirka can work around the problem by autoreconfing during
> the RPM build and ping the libtool maintainers to finally fix this.
> >
> > Brice
> >
> > ___
> > hwloc-devel mailing list
> > hwloc-de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
>

Re: [OMPI devel] [OMPI bugs] [Open MPI] #3592: btl_openib: change SRQ defaults

[Joshua Ladd]

Reviewed by Mike D.

Josh

-Original Message-
From: bugs-boun...@open-mpi.org [mailto:bugs-boun...@open-mpi.org] On Behalf Of 
Open MPI
Sent: Thursday, May 02, 2013 9:10 AM
Cc: b...@open-mpi.org
Subject: [OMPI bugs] [Open MPI] #3592: btl_openib: change SRQ defaults

#3592: btl_openib: change SRQ defaults
---+
Reporter:  amikheev|  Owner:
Type:  changeset move request  | Status:  new
Priority:  major   |  Milestone:  Open MPI 1.7.2
 Version:  trunk   |   Keywords:
---+
 Apply r28440 and r28441 to 1.7 branch

-- 
Ticket URL: 
Open MPI 

___
bugs mailing list
b...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/bugs

Re: [hwloc-devel] hwloc-1.7 issue roundup

[Pavan Balaji]

Perfect.  Thanks.

 -- Pavan

On 05/07/2013 10:07 AM US Central Time, Brice Goglin wrote:
> We got several important bug reports (and fixes) in the last days. I
> think we don't need anything new aside from the pending LTDL fix. So
> let's say within 2 weeks.
> 
> Brice
> 
> 
> Le 07/05/2013 16:59, Pavan Balaji a écrit :
>> Thanks Brice.  What's the timeframe for 1.7.1?  I want to see if we can
>> move to that for our mpich-3.1 release.
>>
>>  -- Pavan
>>
>> On 05/07/2013 09:53 AM US Central Time, Brice Goglin wrote:
>>> Pavan,
>>>
>>> I just pushed another round of commits to trunk, which hopefully address
>>> everything said earlier (except the LDTL problem waiting for Jeff's review).
>>>
>>> 1) autogen args
>>> https://svn.open-mpi.org/trac/hwloc/changeset/5586
>>> 2) sys/sysctl.h #ifdef fix
>>> https://svn.open-mpi.org/trac/hwloc/changeset/5587
>>> 3) sysctl/sysctlbyname check fix (include additional fix for icc)
>>> https://svn.open-mpi.org/trac/hwloc/changeset/5598
>>> 4) HWLOC_CHECK_DECL improvement
>>> https://svn.open-mpi.org/trac/hwloc/changeset/5599
>>> 5) strtoull check
>>> https://svn.open-mpi.org/trac/hwloc/changeset/5600
>>>
>>> (1) and (2) will be backported to v1.7 once regression testing is done.
>>> (5) should likely be OK too.
>>> (3) and more importantly (4) touch ugly configury, I am not sure I want
>>> to backport these. Or maybe later, in case we get more testing before
>>> v1.7.1 occurs.
>>>
>>> Brice
>>>
>>>
>>>
>>>
>>> Le 05/05/2013 18:18, Pavan Balaji a écrit :
 All,

 Sorry for starting a new thread.  I'm trying to round-up all the issues
 I've reported for hwloc-1.7 so far into a more manageable format.

 1. We had noticed errors with -D_POSIX_SOURCE that I had reported here:

 http://www.open-mpi.org/community/lists/hwloc-devel/2013/04/3649.php

 The error with POSIX_SOURCE itself was pretty straightforward.  I was
 able to fix it in the mpich version:

 http://git.mpich.org/mpich.git/commitdiff/255da3f6

 However, with our complete strict build flags, there were more errors.
 Here's a summary and the relevant fixes:

  - hwloc's check for whether an explicitly function declaration is
 needed (using _HWLOC_CHECK_DECL) was relying on whether a dummy call to
 the function throws an error.  This only works if the function
 declaration is already present in one of the headers.  If such a
 declaration is not present, the test might fail with "implicit function
 declaration" with the right CFLAGS.  This leads the m4 macro to think
 that the declaration is already there in one of the headers and an
 additional declaration is not needed.

 The below commit fixes this by adding a dummy function declaration,
 together with the dummy function definition:

 http://git.mpich.org/mpich.git/commitdiff/90da6e90

 FWIW, mpich's version of this macro also uses a similar dummy function
 declaration together with the dummy call to the function:

 http://git.mpich.org/mpich.git/blob/HEAD:/confdb/aclocal_cc.m4#l1215

  - For sysctl and sysctlbyname, I've updated hwloc/config.m4 to use a
 full link test instead of just using AC_CHECK_FUNCS, which only checks
 to see if the symbol exists or not.  For example, the prototype of
 sysctl uses u_int, which on some platforms (such as FreeBSD) is only
 defined under __BSD_VISIBLE, __USE_BSD or other similar definitions.  So
 while the symbols "sysctl" and "sysctlbyname" might still be available
 in libc (which autoconf checks for), they might not be actually usable.

 The below commit fixes this:

 http://git.mpich.org/mpich.git/commitdiff/db276e4e

  - A minor error where strings.h was not included for strcasecmp.

 http://git.mpich.org/mpich.git/commitdiff/d2338c2d

 2. I had reported an issue with libltdl in embedded mode (also in the
 above thread).  I believe Brice is looking into this, so I didn't
 investigate it further.  I'm using a disgusting, but workable, patch to
 workaround this error in mpich (see the
 src/pm/hydra/tools/topo/hwloc/hwloc/src/Makefile.am part of the below
 patch):

 http://git.mpich.org/mpich.git/commitdiff/a3bce754

 I'd appreciate a cleaner fix to this issue.

 3. I had reported an issue with the usage of getpagesize() instead of
 hwloc_getpagesize() on the Mac.

 http://www.open-mpi.org/community/lists/hwloc-devel/2013/05/3662.php

 I believe Samuel has already incorporated this in hwloc trunk.  Here is
 the fix I used for your reference:

 http://git.mpich.org/mpich.git/commitdiff/d9a67f40

 4. I had reported some warnings on the FreeBSD strict build here.

 http://www.open-mpi.org/community/lists/hwloc-devel/2013/05/3669.php

 I believe Brice and Samuel are looking into it, but I don't have a
 confirmation on 

Re: [hwloc-devel] hwloc-1.7 issue roundup

[Brice Goglin]

We got several important bug reports (and fixes) in the last days. I
think we don't need anything new aside from the pending LTDL fix. So
let's say within 2 weeks.

Brice


Le 07/05/2013 16:59, Pavan Balaji a écrit :
> Thanks Brice.  What's the timeframe for 1.7.1?  I want to see if we can
> move to that for our mpich-3.1 release.
>
>  -- Pavan
>
> On 05/07/2013 09:53 AM US Central Time, Brice Goglin wrote:
>> Pavan,
>>
>> I just pushed another round of commits to trunk, which hopefully address
>> everything said earlier (except the LDTL problem waiting for Jeff's review).
>>
>> 1) autogen args
>> https://svn.open-mpi.org/trac/hwloc/changeset/5586
>> 2) sys/sysctl.h #ifdef fix
>> https://svn.open-mpi.org/trac/hwloc/changeset/5587
>> 3) sysctl/sysctlbyname check fix (include additional fix for icc)
>> https://svn.open-mpi.org/trac/hwloc/changeset/5598
>> 4) HWLOC_CHECK_DECL improvement
>> https://svn.open-mpi.org/trac/hwloc/changeset/5599
>> 5) strtoull check
>> https://svn.open-mpi.org/trac/hwloc/changeset/5600
>>
>> (1) and (2) will be backported to v1.7 once regression testing is done.
>> (5) should likely be OK too.
>> (3) and more importantly (4) touch ugly configury, I am not sure I want
>> to backport these. Or maybe later, in case we get more testing before
>> v1.7.1 occurs.
>>
>> Brice
>>
>>
>>
>>
>> Le 05/05/2013 18:18, Pavan Balaji a écrit :
>>> All,
>>>
>>> Sorry for starting a new thread.  I'm trying to round-up all the issues
>>> I've reported for hwloc-1.7 so far into a more manageable format.
>>>
>>> 1. We had noticed errors with -D_POSIX_SOURCE that I had reported here:
>>>
>>> http://www.open-mpi.org/community/lists/hwloc-devel/2013/04/3649.php
>>>
>>> The error with POSIX_SOURCE itself was pretty straightforward.  I was
>>> able to fix it in the mpich version:
>>>
>>> http://git.mpich.org/mpich.git/commitdiff/255da3f6
>>>
>>> However, with our complete strict build flags, there were more errors.
>>> Here's a summary and the relevant fixes:
>>>
>>>  - hwloc's check for whether an explicitly function declaration is
>>> needed (using _HWLOC_CHECK_DECL) was relying on whether a dummy call to
>>> the function throws an error.  This only works if the function
>>> declaration is already present in one of the headers.  If such a
>>> declaration is not present, the test might fail with "implicit function
>>> declaration" with the right CFLAGS.  This leads the m4 macro to think
>>> that the declaration is already there in one of the headers and an
>>> additional declaration is not needed.
>>>
>>> The below commit fixes this by adding a dummy function declaration,
>>> together with the dummy function definition:
>>>
>>> http://git.mpich.org/mpich.git/commitdiff/90da6e90
>>>
>>> FWIW, mpich's version of this macro also uses a similar dummy function
>>> declaration together with the dummy call to the function:
>>>
>>> http://git.mpich.org/mpich.git/blob/HEAD:/confdb/aclocal_cc.m4#l1215
>>>
>>>  - For sysctl and sysctlbyname, I've updated hwloc/config.m4 to use a
>>> full link test instead of just using AC_CHECK_FUNCS, which only checks
>>> to see if the symbol exists or not.  For example, the prototype of
>>> sysctl uses u_int, which on some platforms (such as FreeBSD) is only
>>> defined under __BSD_VISIBLE, __USE_BSD or other similar definitions.  So
>>> while the symbols "sysctl" and "sysctlbyname" might still be available
>>> in libc (which autoconf checks for), they might not be actually usable.
>>>
>>> The below commit fixes this:
>>>
>>> http://git.mpich.org/mpich.git/commitdiff/db276e4e
>>>
>>>  - A minor error where strings.h was not included for strcasecmp.
>>>
>>> http://git.mpich.org/mpich.git/commitdiff/d2338c2d
>>>
>>> 2. I had reported an issue with libltdl in embedded mode (also in the
>>> above thread).  I believe Brice is looking into this, so I didn't
>>> investigate it further.  I'm using a disgusting, but workable, patch to
>>> workaround this error in mpich (see the
>>> src/pm/hydra/tools/topo/hwloc/hwloc/src/Makefile.am part of the below
>>> patch):
>>>
>>> http://git.mpich.org/mpich.git/commitdiff/a3bce754
>>>
>>> I'd appreciate a cleaner fix to this issue.
>>>
>>> 3. I had reported an issue with the usage of getpagesize() instead of
>>> hwloc_getpagesize() on the Mac.
>>>
>>> http://www.open-mpi.org/community/lists/hwloc-devel/2013/05/3662.php
>>>
>>> I believe Samuel has already incorporated this in hwloc trunk.  Here is
>>> the fix I used for your reference:
>>>
>>> http://git.mpich.org/mpich.git/commitdiff/d9a67f40
>>>
>>> 4. I had reported some warnings on the FreeBSD strict build here.
>>>
>>> http://www.open-mpi.org/community/lists/hwloc-devel/2013/05/3669.php
>>>
>>> I believe Brice and Samuel are looking into it, but I don't have a
>>> confirmation on whether this is fixed.  I didn't fix them in mpich yet.
>>>
>>> As you can tell, we are looking into upgrading to hwloc-1.7 for the next
>>> major release of mpich (3.1).  With the above fixes, it looks like
>>> things 

Re: [hwloc-devel] hwloc-1.7 issue roundup

[Pavan Balaji]

Thanks Brice.  What's the timeframe for 1.7.1?  I want to see if we can
move to that for our mpich-3.1 release.

 -- Pavan

On 05/07/2013 09:53 AM US Central Time, Brice Goglin wrote:
> Pavan,
> 
> I just pushed another round of commits to trunk, which hopefully address
> everything said earlier (except the LDTL problem waiting for Jeff's review).
> 
> 1) autogen args
> https://svn.open-mpi.org/trac/hwloc/changeset/5586
> 2) sys/sysctl.h #ifdef fix
> https://svn.open-mpi.org/trac/hwloc/changeset/5587
> 3) sysctl/sysctlbyname check fix (include additional fix for icc)
> https://svn.open-mpi.org/trac/hwloc/changeset/5598
> 4) HWLOC_CHECK_DECL improvement
> https://svn.open-mpi.org/trac/hwloc/changeset/5599
> 5) strtoull check
> https://svn.open-mpi.org/trac/hwloc/changeset/5600
> 
> (1) and (2) will be backported to v1.7 once regression testing is done.
> (5) should likely be OK too.
> (3) and more importantly (4) touch ugly configury, I am not sure I want
> to backport these. Or maybe later, in case we get more testing before
> v1.7.1 occurs.
> 
> Brice
> 
> 
> 
> 
> Le 05/05/2013 18:18, Pavan Balaji a écrit :
>> All,
>>
>> Sorry for starting a new thread.  I'm trying to round-up all the issues
>> I've reported for hwloc-1.7 so far into a more manageable format.
>>
>> 1. We had noticed errors with -D_POSIX_SOURCE that I had reported here:
>>
>> http://www.open-mpi.org/community/lists/hwloc-devel/2013/04/3649.php
>>
>> The error with POSIX_SOURCE itself was pretty straightforward.  I was
>> able to fix it in the mpich version:
>>
>> http://git.mpich.org/mpich.git/commitdiff/255da3f6
>>
>> However, with our complete strict build flags, there were more errors.
>> Here's a summary and the relevant fixes:
>>
>>  - hwloc's check for whether an explicitly function declaration is
>> needed (using _HWLOC_CHECK_DECL) was relying on whether a dummy call to
>> the function throws an error.  This only works if the function
>> declaration is already present in one of the headers.  If such a
>> declaration is not present, the test might fail with "implicit function
>> declaration" with the right CFLAGS.  This leads the m4 macro to think
>> that the declaration is already there in one of the headers and an
>> additional declaration is not needed.
>>
>> The below commit fixes this by adding a dummy function declaration,
>> together with the dummy function definition:
>>
>> http://git.mpich.org/mpich.git/commitdiff/90da6e90
>>
>> FWIW, mpich's version of this macro also uses a similar dummy function
>> declaration together with the dummy call to the function:
>>
>> http://git.mpich.org/mpich.git/blob/HEAD:/confdb/aclocal_cc.m4#l1215
>>
>>  - For sysctl and sysctlbyname, I've updated hwloc/config.m4 to use a
>> full link test instead of just using AC_CHECK_FUNCS, which only checks
>> to see if the symbol exists or not.  For example, the prototype of
>> sysctl uses u_int, which on some platforms (such as FreeBSD) is only
>> defined under __BSD_VISIBLE, __USE_BSD or other similar definitions.  So
>> while the symbols "sysctl" and "sysctlbyname" might still be available
>> in libc (which autoconf checks for), they might not be actually usable.
>>
>> The below commit fixes this:
>>
>> http://git.mpich.org/mpich.git/commitdiff/db276e4e
>>
>>  - A minor error where strings.h was not included for strcasecmp.
>>
>> http://git.mpich.org/mpich.git/commitdiff/d2338c2d
>>
>> 2. I had reported an issue with libltdl in embedded mode (also in the
>> above thread).  I believe Brice is looking into this, so I didn't
>> investigate it further.  I'm using a disgusting, but workable, patch to
>> workaround this error in mpich (see the
>> src/pm/hydra/tools/topo/hwloc/hwloc/src/Makefile.am part of the below
>> patch):
>>
>> http://git.mpich.org/mpich.git/commitdiff/a3bce754
>>
>> I'd appreciate a cleaner fix to this issue.
>>
>> 3. I had reported an issue with the usage of getpagesize() instead of
>> hwloc_getpagesize() on the Mac.
>>
>> http://www.open-mpi.org/community/lists/hwloc-devel/2013/05/3662.php
>>
>> I believe Samuel has already incorporated this in hwloc trunk.  Here is
>> the fix I used for your reference:
>>
>> http://git.mpich.org/mpich.git/commitdiff/d9a67f40
>>
>> 4. I had reported some warnings on the FreeBSD strict build here.
>>
>> http://www.open-mpi.org/community/lists/hwloc-devel/2013/05/3669.php
>>
>> I believe Brice and Samuel are looking into it, but I don't have a
>> confirmation on whether this is fixed.  I didn't fix them in mpich yet.
>>
>> As you can tell, we are looking into upgrading to hwloc-1.7 for the next
>> major release of mpich (3.1).  With the above fixes, it looks like
>> things are working well.  Of course, we'll be going through a lot more
>> testing before the final release which would be later this year.
>>
>>  -- Pavan
>>
> 

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji

Re: [hwloc-devel] hwloc-1.7 issue roundup

[Brice Goglin]

Pavan,

I just pushed another round of commits to trunk, which hopefully address
everything said earlier (except the LDTL problem waiting for Jeff's review).

1) autogen args
https://svn.open-mpi.org/trac/hwloc/changeset/5586
2) sys/sysctl.h #ifdef fix
https://svn.open-mpi.org/trac/hwloc/changeset/5587
3) sysctl/sysctlbyname check fix (include additional fix for icc)
https://svn.open-mpi.org/trac/hwloc/changeset/5598
4) HWLOC_CHECK_DECL improvement
https://svn.open-mpi.org/trac/hwloc/changeset/5599
5) strtoull check
https://svn.open-mpi.org/trac/hwloc/changeset/5600

(1) and (2) will be backported to v1.7 once regression testing is done.
(5) should likely be OK too.
(3) and more importantly (4) touch ugly configury, I am not sure I want
to backport these. Or maybe later, in case we get more testing before
v1.7.1 occurs.

Brice




Le 05/05/2013 18:18, Pavan Balaji a écrit :
> All,
>
> Sorry for starting a new thread.  I'm trying to round-up all the issues
> I've reported for hwloc-1.7 so far into a more manageable format.
>
> 1. We had noticed errors with -D_POSIX_SOURCE that I had reported here:
>
> http://www.open-mpi.org/community/lists/hwloc-devel/2013/04/3649.php
>
> The error with POSIX_SOURCE itself was pretty straightforward.  I was
> able to fix it in the mpich version:
>
> http://git.mpich.org/mpich.git/commitdiff/255da3f6
>
> However, with our complete strict build flags, there were more errors.
> Here's a summary and the relevant fixes:
>
>  - hwloc's check for whether an explicitly function declaration is
> needed (using _HWLOC_CHECK_DECL) was relying on whether a dummy call to
> the function throws an error.  This only works if the function
> declaration is already present in one of the headers.  If such a
> declaration is not present, the test might fail with "implicit function
> declaration" with the right CFLAGS.  This leads the m4 macro to think
> that the declaration is already there in one of the headers and an
> additional declaration is not needed.
>
> The below commit fixes this by adding a dummy function declaration,
> together with the dummy function definition:
>
> http://git.mpich.org/mpich.git/commitdiff/90da6e90
>
> FWIW, mpich's version of this macro also uses a similar dummy function
> declaration together with the dummy call to the function:
>
> http://git.mpich.org/mpich.git/blob/HEAD:/confdb/aclocal_cc.m4#l1215
>
>  - For sysctl and sysctlbyname, I've updated hwloc/config.m4 to use a
> full link test instead of just using AC_CHECK_FUNCS, which only checks
> to see if the symbol exists or not.  For example, the prototype of
> sysctl uses u_int, which on some platforms (such as FreeBSD) is only
> defined under __BSD_VISIBLE, __USE_BSD or other similar definitions.  So
> while the symbols "sysctl" and "sysctlbyname" might still be available
> in libc (which autoconf checks for), they might not be actually usable.
>
> The below commit fixes this:
>
> http://git.mpich.org/mpich.git/commitdiff/db276e4e
>
>  - A minor error where strings.h was not included for strcasecmp.
>
> http://git.mpich.org/mpich.git/commitdiff/d2338c2d
>
> 2. I had reported an issue with libltdl in embedded mode (also in the
> above thread).  I believe Brice is looking into this, so I didn't
> investigate it further.  I'm using a disgusting, but workable, patch to
> workaround this error in mpich (see the
> src/pm/hydra/tools/topo/hwloc/hwloc/src/Makefile.am part of the below
> patch):
>
> http://git.mpich.org/mpich.git/commitdiff/a3bce754
>
> I'd appreciate a cleaner fix to this issue.
>
> 3. I had reported an issue with the usage of getpagesize() instead of
> hwloc_getpagesize() on the Mac.
>
> http://www.open-mpi.org/community/lists/hwloc-devel/2013/05/3662.php
>
> I believe Samuel has already incorporated this in hwloc trunk.  Here is
> the fix I used for your reference:
>
> http://git.mpich.org/mpich.git/commitdiff/d9a67f40
>
> 4. I had reported some warnings on the FreeBSD strict build here.
>
> http://www.open-mpi.org/community/lists/hwloc-devel/2013/05/3669.php
>
> I believe Brice and Samuel are looking into it, but I don't have a
> confirmation on whether this is fixed.  I didn't fix them in mpich yet.
>
> As you can tell, we are looking into upgrading to hwloc-1.7 for the next
> major release of mpich (3.1).  With the above fixes, it looks like
> things are working well.  Of course, we'll be going through a lot more
> testing before the final release which would be later this year.
>
>  -- Pavan
>

Re: [OMPI devel] [OMPI svn] svn:open-mpi r28456 - trunk

[Ralph Castain]

Crud - it just struck me that you don't want to do one thing in that patch.

> + Avoid adding "ignored" frameworks to the autogenerated "frameworks.h"
>  header file.


We use the frameworks.h file to "discover" the frameworks in ompi_info. Even if 
no components are built for that framework, there still are MCA params relating 
to the base of that framework. Sounds silly, I know - but there may be reasons 
to access those params - e.g., to set verbosity to verify that no components 
are being selected.

I think we need those frameworks to be listed...


On May 7, 2013, at 6:49 AM, Ralph Castain  wrote:

> 
> On May 7, 2013, at 6:19 AM, Jeff Squyres (jsquyres)  
> wrote:
> 
>> On May 6, 2013, at 10:39 PM, Ralph Castain  wrote:
>> 
>>> Could someone help me out a bit here:
>>> 
>>> * I'm unaware of any mechanism for "ignoring" an entire framework. Was 
>>> something added for that purpose?
>> 
>> It's been in autogen.pl for a while -- check out the end of 
>> mca_process_framework() in autogen.pl.
> 
> I see - you didn't mean "ignore the framework", you meant "ignore all 
> components in this framework". The two are not the same thing. Ignoring the 
> framework would mean that we were somehow going to skip the base as well, 
> which couldn't possibly work. We've talked about that before and never could 
> figure out how to null-out all the framework level functions.
> 
>> 
>>> * What "non-MCA" projects are in our repository? Everything appears to be 
>>> based on MCA plugins.
>>> 
>>> * Looking at Trac, we eliminated all project/config directories when we did 
>>> the OMPI-RTE abstraction. So what are we looping across at the end of 
>>> autogen?
>> 
>> Yes, we did.  ORNL specifically asked me/Nathan off-list if they could add 
>> this loop in, because they have some off-trunk repos (e.g., STCI) that both 
>> still use the config/ directory stuff and have non-MCA projects.  I didn't 
>> see any harm in these things; e.g., the loop only adds -I if the directory 
>> exists.  I.e., I saw it as being an attempt to be friendly to those who are 
>> trying to use our lower laters (ORTE and/or OPAL) with non-OMPI projects.  I 
>> thought this fit in well with the move-the-BTLs-down-to-OPAL philosophy.
>> 
>> That being said, if others disagree -- e.g., Ralph has a valid point: this 
>> is to help projects that are outside of our trunk -- let's discuss.  This 
>> will probably be a useful topic to discuss today on the teleconf.
> 
> I don't object to it being there as it is a "no-op" for us - there was just 
> no explanation given as to why this was being done. So it looked like a patch 
> based on an old version of the trunk.
> 
> 
>> 
>> -- 
>> 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
> 

Re: [OMPI devel] Q: project based MCA param files

[Ralph Castain]

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, 
_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)  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" 
>> Subject: Re: Q: project based MCA param files
>> Date: May 3, 2013 5:03:43 PM EDT
>> To: "Jeff Squyres (jsquyres)" 
>> Cc: Nathan Hjelm , "Vallee, Geoffroy R." 
>> , "Naughton III, Thomas J." 
>> 
>> 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  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 
 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
>> 

Re: [OMPI devel] [OMPI svn] svn:open-mpi r28456 - trunk

[Ralph Castain]

On May 7, 2013, at 6:19 AM, Jeff Squyres (jsquyres)  wrote:

> On May 6, 2013, at 10:39 PM, Ralph Castain  wrote:
> 
>> Could someone help me out a bit here:
>> 
>> * I'm unaware of any mechanism for "ignoring" an entire framework. Was 
>> something added for that purpose?
> 
> It's been in autogen.pl for a while -- check out the end of 
> mca_process_framework() in autogen.pl.

I see - you didn't mean "ignore the framework", you meant "ignore all 
components in this framework". The two are not the same thing. Ignoring the 
framework would mean that we were somehow going to skip the base as well, which 
couldn't possibly work. We've talked about that before and never could figure 
out how to null-out all the framework level functions.

> 
>> * What "non-MCA" projects are in our repository? Everything appears to be 
>> based on MCA plugins.
>> 
>> * Looking at Trac, we eliminated all project/config directories when we did 
>> the OMPI-RTE abstraction. So what are we looping across at the end of 
>> autogen?
> 
> Yes, we did.  ORNL specifically asked me/Nathan off-list if they could add 
> this loop in, because they have some off-trunk repos (e.g., STCI) that both 
> still use the config/ directory stuff and have non-MCA projects.  I didn't 
> see any harm in these things; e.g., the loop only adds -I if the directory 
> exists.  I.e., I saw it as being an attempt to be friendly to those who are 
> trying to use our lower laters (ORTE and/or OPAL) with non-OMPI projects.  I 
> thought this fit in well with the move-the-BTLs-down-to-OPAL philosophy.
> 
> That being said, if others disagree -- e.g., Ralph has a valid point: this is 
> to help projects that are outside of our trunk -- let's discuss.  This will 
> probably be a useful topic to discuss today on the teleconf.

I don't object to it being there as it is a "no-op" for us - there was just no 
explanation given as to why this was being done. So it looked like a patch 
based on an old version of the trunk.


> 
> -- 
> 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

[OMPI devel] Fwd: Q: project based MCA param files

[Jeff Squyres (jsquyres)]

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" 
> Subject: Re: Q: project based MCA param files
> Date: May 3, 2013 5:03:43 PM EDT
> To: "Jeff Squyres (jsquyres)" 
> Cc: Nathan Hjelm , "Vallee, Geoffroy R." 
> , "Naughton III, Thomas J." 
> 
> 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  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 
>>> 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  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
>> 

Re: [OMPI devel] [OMPI svn] svn:open-mpi r28456 - trunk

[Jeff Squyres (jsquyres)]

On May 6, 2013, at 10:39 PM, Ralph Castain  wrote:

> Could someone help me out a bit here:
> 
> * I'm unaware of any mechanism for "ignoring" an entire framework. Was 
> something added for that purpose?

It's been in autogen.pl for a while -- check out the end of 
mca_process_framework() in autogen.pl.

> * What "non-MCA" projects are in our repository? Everything appears to be 
> based on MCA plugins.
> 
> * Looking at Trac, we eliminated all project/config directories when we did 
> the OMPI-RTE abstraction. So what are we looping across at the end of autogen?

Yes, we did.  ORNL specifically asked me/Nathan off-list if they could add this 
loop in, because they have some off-trunk repos (e.g., STCI) that both still 
use the config/ directory stuff and have non-MCA projects.  I didn't see any 
harm in these things; e.g., the loop only adds -I if the directory exists.  
I.e., I saw it as being an attempt to be friendly to those who are trying to 
use our lower laters (ORTE and/or OPAL) with non-OMPI projects.  I thought this 
fit in well with the move-the-BTLs-down-to-OPAL philosophy.

That being said, if others disagree -- e.g., Ralph has a valid point: this is 
to help projects that are outside of our trunk -- let's discuss.  This will 
probably be a useful topic to discuss today on the teleconf.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/