[Pkg-openmpi-maintainers] Bug#376833: Bug#376833: Next steps
edd at debian.org
Tue Mar 18 16:10:32 UTC 2008
Hi Jeff et al,
Thanks for the follow-up! Lots of good points raised, I'll try to reply 'in
full' and apologize in advance for the length of the email.
On 18 March 2008 at 08:58, Jeff Squyres wrote:
| On Mar 11, 2008, at 4:51 AM, Adam C Powell IV wrote:
| >> [ Jeff/Tim: This is about the outstanding Debian bug report(s)
| >> regarding the
| >> architectures without atomic ops -- where we cannot build Open MPI.
| >> It has
| >> been suggested in the past to try libatomic-ops-dev which seems to
| >> lack one
| >> or two instructions needed by Open Mpi ]
| Good context; thanks.
| >> On 8 March 2008 at 09:12, Adam C Powell IV wrote:
| >> | Hi Dirk,
| >> |
| >> | I'm afraid I don't have a lot of time just now, but to me next
| >> steps
| >> | seem like:
| >> | 1. Install libatomic-ops-dev.
| >> | 2. Try building openmpi without the included atomic ops and
| >> with
| >> | this lib.
| >> | 3. If it works, great! If it doesn't, try to adjust the calls
| >> | and/or ask on the openmpi mailing list.
| >> | 4. If they suggest a workaround, great! If not, wishlist
| >> | libatomic-ops-dev to add the needed functionality.
| >> | 5. When everything works, push the change upstream.
| >> |
| >> | If you don't get to it first, I can do 1-2 in about 2-3 weeks...
| >> Do you have access to any of the missing arches without atomic ops
| >> from
| >> upstream?
| > No, but if it works on the existing arches, it should work on the
| > missing ones, right? Furthermore, if the ops happen to be the same,
| > what's to say upstream didn't get them from this lib in the first
| > place?
| > [Jeff/Tim, I welcome your comments...]
| The guy who did the majority of atomic assembly is no longer on the
| project :-(, so I can't say for sure where they came from. It was
| probably a mixture of many different sources, such as instruction
| manuals for the chipsets involved, etc.
| 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 ]
m68k [ though that architecture may get purged ... ]
mips [ there are some compute blades using this IIRC ]
For these we can fall back to LAM but that is kinda lame (bad pun alert).
| >> Or are you in fact suggesting that supplant what upstream has with
| >> libatomic-ops-dev? I would hesitate a great before doing that -- I
| >> tend to
| >> trust upstream in these matters.
| > That's fair. On the other hand, it can't hurt to try it, and we
| > have a
| > good bit of time now for users to test it before the lenny release.
| > If
| > nothing else, it's worth giving it a go in experimental. As I said,
| > if
| > you don't get it to it in a couple of weeks, I'll give it a go.
| I'm afraid I know nothing about libatomic-ops-dev -- I did a few quick/
| lame google searches and couldn't turn up a home page for this project
| (including on debian.org). Could someone point me in the right
| We can investigate it and see if it meets our needs.
[ You can reply on the file debian/copyright to point to the upstream
sources; and these Debian files are visibile via the 'package tracking
system' pages eg http://packages.qa.debian.org/liba/libatomic-ops.html -- and
I do not mean to imply that you could or should have known that.
This PTS also shows that the package is actively maintained: recent upoads,
no bugs. Good! ]
The copyright at
says downloaded from
and lists Hans Boehm and David Mosberger as authors, with their hp.com
addresses and with HP as copyright holders. Pestering these famous kernel
hackers may be next on our agenda then :)
Is/Was HP part of Open MPI ? Or are they 'neutral', or worse in 'enemy
| > Debian has generally emphasized sharing code wherever possible. So
| > for
| > example, ffmpeg and mplayer have been strongly urged to do what it
| > takes
| > to share the decoder libraries, which are developed together, though
| > the
| > release schedules of those two "front ends" have been very different.
| > Likewise, I shoehorned the pysparse python sparse solver front end to
| > fit with Debian's superlu and umfpack (suitesparse package)
| > libraries in
| > place of the versions provided in the upstream source. I think the
| > same
| > principal is at work here.
| Without knowing anything about libatomics-ops-dev, three roadblocks to
| integrating libatomic-ops-dev into Open MPI could be:
| 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.
| 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.
| 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.
Right. Or, if it is small, just pull it in. License permitting etc pp [
Though as I said, we prefer using existing libraries but I understand that
yoru agenda is driven by different concerns. ]
| >> Generally speaking, it may be worthwhile going to upstream now. So
| >> lemme CC
| >> them, as well as co-maintainer Manuel.
| > Good idea. I often work with non-responsive upstream developers, so
| > my
| > first recourse is usually to "just do it", but thankfully that is not
| > the case with openmpi.
| We're not always quick to reply, but we try. :-)
| >> I should point out to Jeff and Tim that we do get quasi-constant
| >> grief about
| >> Open MPI not spanning the Debian universe of arches. I personally
| >> fall back
| >> to Lam where Open MPI is missing but that is indeed somewhat cheesy.
| >> Longer-term, full support across all hardware platform would be
| >> great.
| >> But I am talking way out of area of expertise here -- what do you
| >> upstream
| >> guys think? Let us have it, and don't hold back.
| The biggest problem is maintenance. I can't easily justify to my
| employer spending time on maintenance of platforms that we officially
| don't care about. Such is true with many of the other Open MPI
| developers -- we don't really have someone who is "batting cleanup" to
| pick up all the loose odds and ends on platforms that aren't
| officially supported. :-\
Understood. Maybe you can get the IBM folks to look after s390 ;-)
| If libatomic-ops-dev can fix some of these problems (by automatically
| picking up [atomic ops] support on some platforms that we don't
| actively support, especially since our main assembly developer is now
| gone), that would be great. But it'll require some investigation first.
| I should also point out that we're gearing up for branching for the
| v1.3 series and are rushing to finish some critical features before
| deadline. To be honest and not inflate expectations, I kinda doubt
| that we'll have the time to be able to perform due diligence on
| libatomic-ops-dev and/or integrate it before 1.3 branching. :-(
Debian is not worried about quarterly performance reports so for as long as
we get some pieces on motion, I'd be perfectly happy to defer to this to
1.3.$x with $x 'high' or even 1.4.0. We are patient :) I just spent 18+
months working with Argonne and the original author to get PGAPack relicensed
and back into Debian's main ;-)
We want to do this right.
Thanks for listening, Dirk
Three out of two people have difficulties with fractions.
More information about the Pkg-openmpi-maintainers