[Pkg-openmpi-maintainers] Bug#376833: Bug#376833: Next steps

[Jeff Squyres]

Guess what?  Brian sent a long list of thoughts and a patch for "75%  
of the work" to support libatomic-ops in Open MPI (as a backup for  
platforms that we don't support with our native assembly).  The  
remaining 25% requires access to the platforms that we don't support  
-- so perhaps that's appropriate for you guys to tackle...?

I put up the information Brian sent on our wiki:

     https://svn.open-mpi.org/trac/ompi/wiki/libatomic-ops

I branched from our SVN trunk and applied his patch -- the SVN URL you  
can check out is (it contains his patch):

     https://svn.open-mpi.org/svn/ompi/tmp-public/libatomic-ops

Be sure to see our "how to compile OMPI from SVN" page:

     http://www.open-mpi.org/svn/building.php

How does this sound?



On Mar 19, 2008, at 9:41 AM, Jeff Squyres wrote:

> On Mar 18, 2008, at 12:10 PM, Dirk Eddelbuettel wrote:
>
>> | What platforms in particular are not supported that Debian wants?
>>
>> We havevery good success with Open MPI on
>>
>> 	i386 amd64 alpha ia64 powerpc sparc
>>
>> and we are out of luck on
>>
>> 	arm    [ and a new variant armel with fpu support was added IIRC ]
>> 	hppa
>> 	m68k   [ though that architecture may get purged ... ]
>> 	mips   [ there are some compute blades using this IIRC ]
>> 	mipsel
>> 	s390
>
> FWIW, I'm not aware of any current OMPI members who care about these  
> platforms.
>
>> The copyright at
>> http://packages.debian.org/changelogs/pool/main/liba/libatomic-ops/current/copyright
>> says downloaded from
>>
>> 	http://www.hpl.hp.com/research/linux/atomic_ops/download.php4
>
> Perfect; thanks.
>
>> Is/Was HP part of Open MPI ?   Or are they 'neutral', or worse in  
>> 'enemy
>> territory' ?
>
> HP is a big company.  :-)
>
> I believe that part of HP doesn't care about Open MPI, but most of  
> the HPC portion HP is probably against Open MPI because HP sells  
> their own MPI (HP MPI).  So HP will likely never be a formal member  
> of the Open MPI Project.
>
> But we all work together; the MPI implementor community is fairly  
> small and many of us know each other.  We have good working  
> relationships.  Part of the goal of Open MPI is to come up with good  
> ideas and let others use them.  :-)
>
>> | 1. license: Open MPI is BSD -- what's libtatomics-ops-dev?
>>
>> Looks similar to me -- but see at the link above.
>>
>> Mentions the GPL for subcomponents tests and sample apps, so looks  
>> like this
>> is not an issue.
>
> I sent the link for the project to a few OMPI developers yesterday,  
> and our collective IANAL opinion is that only one sub-library in  
> libatomics_ops needs to be avoided (because it's specifically GPL)  
> -- all other library bits are MIT and therefore are ok.
>
>> | 2. portability: does it work outside of Linux?  Does it work with  
>> non-
>> | gcc compilers?  The first is surmountable (see below), but the  
>> second
>> | would be quite difficult to fix -- we would likely need fixes  
>> from the
>> | libatomics-ops-dev maintainers.
>>
>> Good points. Dunno -- we tend to be gcc only as far as Debian goes,  
>> but this
>> _should_ be vanilla C.
>
> It's not the C that's the problem -- it's the assembly.  It *looks*  
> like they use inline assembly only, and not all compilers support  
> that.  This is somewhat of a dealbreaker for us -- meaning that we  
> couldn't make this the default / only option available.
>
> More below.
>
>> | 3. distribution: we have a core philosophy of aggressively trying  
>> to
>> | decrease the number of dependencies of Open MPI to enable simple
>> | download/install by novice users (we can't always succeed in  
>> this, but
>> | we do try).  To this point, we have embedded a few "core"  
>> dependencies
>> | in the Open MPI source code distribution itself so that you don't  
>> have
>> | to have them installed to build/run Open MPI (e.g., particularly on
>> | platforms that may not have them already installed, such as OS X or
>> | Solaris).  The atomic operations likely fit into this category such
>> | that the OMPI community may be resistant to requiring a 3rd party
>> | library just to be able to install/run.
>> |
>> | One *possibility* is that we could use the included atomics unless
>> | specifically directed to use libatomic-ops (e.g., via a configure
>> | option such as --with-libatomic-ops=/foo).  There's lots of  
>> "if's" in
>> | there, though -- if the license is compatible, if the library meets
>> | our needs, ...etc.  So we would need to investigate a few things  
>> first.
>
> The consensus yesterday was:
>
> - license looks ok, but needs official review
> - looks like they support all the atomic ops we need except for timers
> - we could probably make a patch for a --with-libatomic-ops  
> configure switch that would swap out our default atomic ops with  
> libatomic_ops
>
> Brian (the developer who isn't officially on our project anymore,  
> but OMPI is still in his heart...) said he could look at making up  
> such a patch.  I wouldn't want to estimate a timeline, though.
>
> We probably will not be embedding this package in Open MPI because:
>
> - it doesn't work for all compilers
> - it doesn't work for all OS's / platforms
> - and therefore it won't be our default/core
>
> Hence, linking to it via an external header / library is fine.
>
> -- 
> Jeff Squyres
> Cisco Systems
>


-- 
Jeff Squyres
Cisco Systems