Re: [hwloc-devel] python bindings testing help needed

2013-06-04 Thread Guy Streeter 
On 06/04/2013 03:52 AM, Brice Goglin wrote:
> (forgot to CC the list)
> 
> 
> Le 04/06/2013 10:48, Brice Goglin a écrit :
>> Hello,
>>
>> Here are some slightly fixed tests. cuda/cudart/nvml look good.
>> intel-mic looks good but I couldn't test on a real machine (I used XML
>> instead), so the cpuset retrieving code wasn't tested.
>>
>> gl doesn't seem to find any GPU, but I don't know enough about Python to
>> debug things. If you have a debugging version, I can test it.
>>

I think my regular expression code is broken in the gl stuff. Do you have to
have the hardware and drivers for GL, or could I use an XML file for testing?

The main thing I need to know is what the "name" of a GPU object really looks
like. Perhaps the output of the hwloc gl test on an appropriate system would 
help.

thanks,
--Guy

Re: [hwloc-devel] First plugin namespace issue report

2013-06-04 Thread Brice Goglin 
Le 04/06/2013 14:34, Jeff Squyres (jsquyres) a écrit :
> On Jun 4, 2013, at 5:11 AM, Brice Goglin  wrote:
>
>> 2) custom test with ltdl: The program just silently fails to load hwloc
>> symbols. Equivalent to passing the topology flag above.
>
> One option might be to try to lt_dlsym one of the hwloc symbols that you know 
> you'll need in the plugin (or any public hwloc symbol, for that matter).  If 
> ltdl_sym gets NULL back for the hwloc global symbol, then the plugin should 
> disqualify itself and have itself unloaded (perhaps with some way of 
> reporting what/why it did that).
>

lt_dlsym doesn't seem to accept special handles such as RTLD_DEFAULT
like dlsym does, and we don't have a handle on hwloc. I don't see how to
do that with lt_dlsym?

Brice

Re: [hwloc-devel] Move to git?

2013-06-04 Thread David Beer 
I know I'm not really an active member of the dev community, but I have
experience with this from working on TORQUE (my full-time job). We switched
to git (hosted on github) and it has been fantastic for us. I was familiar
with git but hardly an expert when we changed over, and the same was true
of a lot of our community. Largely having to learn another tool has been a
non-event and github has had a lot of useful features that have helped us
coordinate with our community better.

I wasn't responsible for switching things, but I believe we used svn2git
and it did change all of the r to git changesets.

David


On Tue, Jun 4, 2013 at 8:05 AM, Nathan Hjelm  wrote:

> Take a look at svn2git. It takes care of some the the tag/branch naming
> problems. If you use it make sure to pass the --metadata option to get the
> git-svn-id's in the commit messages.
>
> -Nathan
>
> On Jun 4, 2013, at 4:23 AM, Brice Goglin  wrote:
>
> > When I switched Open-MX and KNEM from SVN to GIT, I basically just
> > pushed my git-svn clone. But I had to manually convert some svn
> > tags/branches. IIRC, the main reason is that git-svn has a strange way
> > to name svn branches in git.
> >
> > We may also have to pass --authors-file to git svn clone so that SVN
> > logins are converted into proper git author names.
> >
> > Brice
> >
> >
> >
> >
> > Le 04/06/2013 12:14, Jeff Squyres (jsquyres) a écrit :
> >> Ok.  This is kinda what I assumed your response would be.  :-)
> >>
> >> Let me talk to Dave Goodell later today, who just recently went through
> converting MPICH from SVN -> Git, and see what kinds of things we need to
> do to get the ball rolling here, and what kinds of dragons we should expect
> to encounter along the way.
> >>
> >>
> >> On Jun 3, 2013, at 11:17 PM, Brice Goglin 
> wrote:
> >>
> >>> +1000 !
> >>> I already use git-svn for most of my hwloc work. But I still need svn
> for backports, and that wastes a lot of my time.
> >>> Brice
> >>>
> >>>
> >>> "Jeff Squyres (jsquyres)"  a écrit :
> >>> We're having a discussion (again :-) ) about moving OMPI to a DVCS.
> >>>
> >>> The short conclusion of the long conversation is: the OMPI dev
> community would be much more comfortable moving to a DVCS if they could see
> some success with other OMPI projects (e.g., hwloc and/or MTT).
> >>>
> >>> Would hwloc be interested in moving to git?  This would mean:
> >>>
> >>> 1. converting the existing svn to git
> >>> --> including all historical log messages that refer to "r"
> >>> 2. converting the existing trac to git
> >>> --> including all trac tickets, comments, and wiki pages that refer to
> "r"
> >>>
> >>> The OMPI devs -- who are mostly unfamiliar with git -- would like to
> see some close-to-home successes with git over a period of time that don't
> require heavy administrative maintenance over time (one of the pushback
> issues was that some organizations have hired full-time people to
> >>> maintain/fix git repositories when they break/become unusable).
> >>>
> >>>
> >>> Interested?
> >>
> >
> > ___
> > hwloc-devel mailing list
> > hwloc-de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>
>
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>



-- 
David Beer | Senior Software Engineer
Adaptive Computing

Re: [hwloc-devel] Move to git?

2013-06-04 Thread Nathan Hjelm 
Take a look at svn2git. It takes care of some the the tag/branch naming 
problems. If you use it make sure to pass the --metadata option to get the 
git-svn-id's in the commit messages.

-Nathan

On Jun 4, 2013, at 4:23 AM, Brice Goglin  wrote:

> When I switched Open-MX and KNEM from SVN to GIT, I basically just
> pushed my git-svn clone. But I had to manually convert some svn
> tags/branches. IIRC, the main reason is that git-svn has a strange way
> to name svn branches in git.
> 
> We may also have to pass --authors-file to git svn clone so that SVN
> logins are converted into proper git author names.
> 
> Brice
> 
> 
> 
> 
> Le 04/06/2013 12:14, Jeff Squyres (jsquyres) a écrit :
>> Ok.  This is kinda what I assumed your response would be.  :-)
>> 
>> Let me talk to Dave Goodell later today, who just recently went through 
>> converting MPICH from SVN -> Git, and see what kinds of things we need to do 
>> to get the ball rolling here, and what kinds of dragons we should expect to 
>> encounter along the way.
>> 
>> 
>> On Jun 3, 2013, at 11:17 PM, Brice Goglin  wrote:
>> 
>>> +1000 !
>>> I already use git-svn for most of my hwloc work. But I still need svn for 
>>> backports, and that wastes a lot of my time.
>>> Brice
>>> 
>>> 
>>> "Jeff Squyres (jsquyres)"  a écrit :
>>> We're having a discussion (again :-) ) about moving OMPI to a DVCS.
>>> 
>>> The short conclusion of the long conversation is: the OMPI dev community 
>>> would be much more comfortable moving to a DVCS if they could see some 
>>> success with other OMPI projects (e.g., hwloc and/or MTT).
>>> 
>>> Would hwloc be interested in moving to git?  This would mean:
>>> 
>>> 1. converting the existing svn to git
>>> --> including all historical log messages that refer to "r"
>>> 2. converting the existing trac to git
>>> --> including all trac tickets, comments, and wiki pages that refer to 
>>> "r"
>>> 
>>> The OMPI devs -- who are mostly unfamiliar with git -- would like to see 
>>> some close-to-home successes with git over a period of time that don't 
>>> require heavy administrative maintenance over time (one of the pushback 
>>> issues was that some organizations have hired full-time people to
>>> maintain/fix git repositories when they break/become unusable).
>>> 
>>> 
>>> Interested?
>> 
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel

Re: [hwloc-devel] First plugin namespace issue report

2013-06-04 Thread Jeff Squyres (jsquyres) 
On Jun 4, 2013, at 5:22 AM, Brice Goglin  wrote:

> I take that back. Topology flags come too late, plugins are loaded
> during the first topology_init().

Bummer.

> We're back to things like "export HWLOC_PLUGINS_PATH=/none"

Perhaps add a pre-init API to set flags like this...?

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

Re: [hwloc-devel] First plugin namespace issue report

2013-06-04 Thread Jeff Squyres (jsquyres) 
On Jun 4, 2013, at 5:11 AM, Brice Goglin  wrote:

> 2) custom test with ltdl: The program just silently fails to load hwloc
> symbols. Equivalent to passing the topology flag above.


One option might be to try to lt_dlsym one of the hwloc symbols that you know 
you'll need in the plugin (or any public hwloc symbol, for that matter).  If 
ltdl_sym gets NULL back for the hwloc global symbol, then the plugin should 
disqualify itself and have itself unloaded (perhaps with some way of reporting 
what/why it did that).

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

Re: [hwloc-devel] First plugin namespace issue report

2013-06-04 Thread Brice Goglin 
Le 04/06/2013 14:11, Brice Goglin a écrit :
> Adding topology flag to disable plugin may indeed be a nice workaround.
> As long as the hwloc user doesn't need what's in plugin, things will
> work fine. And I think things will work fine in the OpenCL case.
>

I take that back. Topology flags come too late, plugins are loaded
during the first topology_init().
We're back to things like "export HWLOC_PLUGINS_PATH=/none"

Brice

Re: [hwloc-devel] First plugin namespace issue report

2013-06-04 Thread Brice Goglin 
(adding the list to CC)


Le 04/06/2013 13:35, Jeff Squyres (jsquyres) a écrit :
> On Jun 4, 2013, at 4:10 AM, Brice Goglin  wrote:
>
>>> I guess I'm asking - why can't that plugin link against an embedded 
>>> (non-DSO) hwloc?
>> It can for sure. But if there's a hwloc package in your distrib (and
>> this one usually has plugins enabled), people usually force you to use
>> it instead of shipping another hwloc in your own package.
>
> Does hwloc support building its modules in libhwloc.la by default, but also 
> lt_dlopening any modules that it finds?
>
> If so, perhaps passing a flag to hwloc's init saying "don't open any plugins" 
> might be sufficient...?

Once you pass --enable-plugins to get plugin loading support, you can
still have both statically-built-in and plugin at the same time.

The main point for making hwloc plugins was to avoid dependencies on
crazy things like cuda/opencl/nvml/nvctrl/pci/libxml in the hwloc core.
So only these components can be built as plugins, others are always
static (Linux, x86, minimalistic xml without libxml).


Adding topology flag to disable plugin may indeed be a nice workaround.
As long as the hwloc user doesn't need what's in plugin, things will
work fine. And I think things will work fine in the OpenCL case.

Also, we have seen two behaviors:
1) OpenCL: the program aborts because the lazy symbol lookup fails, and
we can't easily force BIND_NOW
2) custom test with ltdl: The program just silently fails to load hwloc
symbols. Equivalent to passing the topology flag above.
I hope we'll see (2) more often than (1) in the future.

Brice

Re: [hwloc-devel] Move to git?

2013-06-04 Thread Jeff Squyres (jsquyres) 
On Jun 4, 2013, at 3:38 AM, Brice Goglin  wrote:

>> I'd like to explore converting all the old SVN log message mentions of 
>> "r" to git hashes.  git-svn doesn't do that, right?
> 
> No it doesn't afaik, and that would be nice.


I know that MPICH went through this (converting all old messages -- both in SVN 
and trac -- from "r" to git hashes).  Let me talk to Dave later today and 
see what they did.

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

Re: [hwloc-devel] Move to git?

2013-06-04 Thread Jeff Squyres (jsquyres) 
On Jun 4, 2013, at 3:23 AM, Brice Goglin  wrote:

> When I switched Open-MX and KNEM from SVN to GIT, I basically just
> pushed my git-svn clone. But I had to manually convert some svn
> tags/branches. IIRC, the main reason is that git-svn has a strange way
> to name svn branches in git.

I'd like to explore converting all the old SVN log message mentions of "r" 
to git hashes.  git-svn doesn't do that, right?

> We may also have to pass --authors-file to git svn clone so that SVN
> logins are converted into proper git author names.

K.

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

Re: [hwloc-devel] plugins inside plugin broken, as expected

2013-06-04 Thread Jeff Squyres (jsquyres) 
On Jun 3, 2013, at 11:11 AM, Samuel Thibault  wrote:

> If only plugins and the core use these functions, the application does
> not have to use -lhwloc-helper at all. If the application uses them
> (e.g. bitmap functions), then it would have to use -lhwloc-helper,
> but we can probably as well simply provide the symbols in both
> libhwloc-helper and libhwloc, so the application only needs -lhwloc.

I don't think you want to go that route -- you can end up with duplicate 
symbols, and there be dragons there.

> We
> can probably do that for the helpers we know for sure they have no
> state, such as bitmap functions.


I don't know if all these elaborate workarounds will be a Good Thing.  You'll 
basically explore the dynamic linker space, in all of its glory/ugliness, and 
end up coming up with horrid, confusing workarounds.

The short version is: issues like this are the nature of DSOs.

Hwloc has a solution for this problem: build without DSO support, and all works 
fine.  That should be the advertised solution, IMNSHO.

Until someone comes up with a more general, system-level solution to the 
problems of plugins loading plugins (e.g., some kind of flexible runtime linker 
namespace solution), individual user-level software packages cannot hope to 
sanely work around what is currently defined as the system model.

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

Re: [hwloc-devel] Move to git?

2013-06-04 Thread Brice Goglin 
When I switched Open-MX and KNEM from SVN to GIT, I basically just
pushed my git-svn clone. But I had to manually convert some svn
tags/branches. IIRC, the main reason is that git-svn has a strange way
to name svn branches in git.

We may also have to pass --authors-file to git svn clone so that SVN
logins are converted into proper git author names.

Brice




Le 04/06/2013 12:14, Jeff Squyres (jsquyres) a écrit :
> Ok.  This is kinda what I assumed your response would be.  :-)
>
> Let me talk to Dave Goodell later today, who just recently went through 
> converting MPICH from SVN -> Git, and see what kinds of things we need to do 
> to get the ball rolling here, and what kinds of dragons we should expect to 
> encounter along the way.
>
>
> On Jun 3, 2013, at 11:17 PM, Brice Goglin  wrote:
>
>> +1000 !
>> I already use git-svn for most of my hwloc work. But I still need svn for 
>> backports, and that wastes a lot of my time.
>> Brice
>>
>>
>> "Jeff Squyres (jsquyres)"  a écrit :
>> We're having a discussion (again :-) ) about moving OMPI to a DVCS.
>>
>> The short conclusion of the long conversation is: the OMPI dev community 
>> would be much more comfortable moving to a DVCS if they could see some 
>> success with other OMPI projects (e.g., hwloc and/or MTT).
>>
>> Would hwloc be interested in moving to git?  This would mean:
>>
>> 1. converting the existing svn to git
>> --> including all historical log messages that refer to "r"
>> 2. converting the existing trac to git
>> --> including all trac tickets, comments, and wiki pages that refer to 
>> "r"
>>
>> The OMPI devs -- who are mostly unfamiliar with git -- would like to see 
>> some close-to-home successes with git over a period of time that don't 
>> require heavy administrative maintenance over time (one of the pushback 
>> issues was that some organizations have hired full-time people to
>> maintain/fix git repositories when they break/become unusable).
>>
>>
>> Interested?
>

Re: [hwloc-devel] Move to git?

2013-06-04 Thread Jeff Squyres (jsquyres) 
Ok.  This is kinda what I assumed your response would be.  :-)

Let me talk to Dave Goodell later today, who just recently went through 
converting MPICH from SVN -> Git, and see what kinds of things we need to do to 
get the ball rolling here, and what kinds of dragons we should expect to 
encounter along the way.


On Jun 3, 2013, at 11:17 PM, Brice Goglin  wrote:

> +1000 !
> I already use git-svn for most of my hwloc work. But I still need svn for 
> backports, and that wastes a lot of my time.
> Brice
> 
> 
> "Jeff Squyres (jsquyres)"  a écrit :
> We're having a discussion (again :-) ) about moving OMPI to a DVCS.
> 
> The short conclusion of the long conversation is: the OMPI dev community 
> would be much more comfortable moving to a DVCS if they could see some 
> success with other OMPI projects (e.g., hwloc and/or MTT).
> 
> Would hwloc be interested in moving to git?  This would mean:
> 
> 1. converting the existing svn to git
> --> including all historical log messages that refer to "r"
> 2. converting the existing trac to git
> --> including all trac tickets, comments, and wiki pages that refer to "r"
> 
> The OMPI devs -- who are mostly unfamiliar with git -- would like to see some 
> close-to-home successes with git over a period of time that don't require 
> heavy administrative maintenance over time (one of the pushback issues was 
> that some organizations have hired full-time people to
> maintain/fix git repositories when they break/become unusable).
> 
> 
> Interested?


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

Re: [hwloc-devel] python bindings testing help needed

2013-06-04 Thread Brice Goglin 
(forgot to CC the list)


Le 04/06/2013 10:48, Brice Goglin a écrit :
> Hello,
>
> Here are some slightly fixed tests. cuda/cudart/nvml look good.
> intel-mic looks good but I couldn't test on a real machine (I used XML
> instead), so the cpuset retrieving code wasn't tested.
>
> gl doesn't seem to find any GPU, but I don't know enough about Python to
> debug things. If you have a debugging version, I can test it.
>
> By the way, I couldn't find a "libnuma" python package so I used "numa"
> in hwloc.py instead (that's what PIP was able to install).
>
> Are you working on OpenCL too?
>
> Brice
>
>
>
> Le 03/06/2013 23:16, Guy Streeter a écrit :
>> I'm getting the hwloc-1.7 version of the python bindings ready to go. I've
>> tried to add GL, Intel MIC, NVML, and CUDA support.
>> I can't implement much of CUDA or NVML for lack of python bindings for those
>> libraries, but I did what I could.
>> I can't test any of these for lack of hardware. If you have a Linux system
>> with some appropriate hardware and you can help, please either:
>>
>> clone the git repo at
>>  git://git.fedorahosted.org/python-hwloc.git
>> and then checkout the 1.7-devel branch
>>
>> or
>>
>> get the tarball from
>>  http://people.redhat.com/streeter/python-hwloc-1.7.tar.bz2
>> and unpack it.
>>
>> Export the PYTHONPATH environment variable to point to the top level
>> directory, then run the various tests, like:
>>
>> python tests/gl.py
>>
>> also cuda.py, cudart.py, intel_mic.py, nvml.py
>>
>> As I said, the CUDA and NVML tests are only partly implemented.
>> All the other tests in the tests directory should match the output of the 
>> same
>> test in the hwloc 1.7 source tree.
>>
>> Let me know how it goes.
>> thanks,
>> --Guy
>> ___
>> hwloc-devel mailing list
>> hwloc-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel

Re: [hwloc-devel] Move to git?

2013-06-04 Thread Brice Goglin 
+1000 !
I already use git-svn for most of my hwloc work. But I still need svn for 
backports, and that wastes a lot of my time.
Brice


"Jeff Squyres (jsquyres)"  a écrit :

>We're having a discussion (again :-) ) about moving OMPI to a DVCS.
>
>The short conclusion of the long conversation is: the OMPI dev
>community would be much more comfortable moving to a DVCS if they could
>see some success with other OMPI projects (e.g., hwloc and/or MTT).
>
>Would hwloc be interested in moving to git?  This would mean:
>
>1. converting the existing svn to git
>   --> including all historical log messages that refer to "r"
>2. converting the existing trac to git
>--> including all trac tickets, comments, and wiki pages that refer to
>"r"
>
>The OMPI devs -- who are mostly unfamiliar with git -- would like to
>see some close-to-home successes with git over a period of time that
>don't require heavy administrative maintenance over time (one of the
>pushback issues was that some organizations have hired full-time people
>to maintain/fix git repositories when they break/become unusable).
>
>Interested?
>
>-- 
>Jeff Squyres
>jsquy...@cisco.com
>For corporate legal information go to:
>http://www.cisco.com/web/about/doing_business/legal/cri/
>
>
>___
>hwloc-devel mailing list
>hwloc-de...@open-mpi.org
>http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel

[hwloc-devel] Move to git?

2013-06-04 Thread Jeff Squyres (jsquyres) 
We're having a discussion (again :-) ) about moving OMPI to a DVCS.

The short conclusion of the long conversation is: the OMPI dev community would 
be much more comfortable moving to a DVCS if they could see some success with 
other OMPI projects (e.g., hwloc and/or MTT).

Would hwloc be interested in moving to git?  This would mean:

1. converting the existing svn to git
   --> including all historical log messages that refer to "r"
2. converting the existing trac to git
   --> including all trac tickets, comments, and wiki pages that refer to 
"r"

The OMPI devs -- who are mostly unfamiliar with git -- would like to see some 
close-to-home successes with git over a period of time that don't require heavy 
administrative maintenance over time (one of the pushback issues was that some 
organizations have hired full-time people to maintain/fix git repositories when 
they break/become unusable).

Interested?

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