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

[Jeff Squyres]

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