Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2007-10-09 06:38:45


On Oct 8, 2007, at 10:00 PM, Andreas Knüpfer wrote:

> - yes, we might move vanmpirtrace to ./ompi/contrib/vampirtrace/,
> why not. but since we agreed on the current location ./tracing/
> vampirtrace/ we should not rush it just because another software is
> coming to openmpi, should we?

I actually always had in my mind that VT should live somewhere under /
ompi -- not in the top-level directory. I'm sorry if I did not
communicate that well.

> - the "call home" feature. I understand you concerns perfectly
> well. we'll
> remove this, If anyone is asking us to. but please let me explain
> first:
>
> 1) it's not in vampirtrace itself but in the parts we added to ompi
> on behalf
> of vampirtrace
> 2) it is never active by default, instead you need a
> special '--update-vampirtrace' switch on your configure command.
> otherwise
> nothing is calling nowhere. is this equivalent to "totally
> deactivated" or
> still not good enough?
> 3) it was our idea to make it easier to replace the included
> vampirtrace
> version if it was necessary. manually download and untar is not
> that much
> harder, though.
> 4) we check if 'wget' is present and try _not_ to make ./configure
> fail
>
> once again, if anybody want's this removed, please say so.

Is this in the production VT, or is this OMPI-specific functionality?

If it's OMPI-specific functionality, I would vote to not have it.

One of my big problems with this idea is that we lose the concept of
shipping a single unit of Open MPI. If someone sends us a bug report
concerning VT, we no longer have a solid idea of what version they
are running because they may have replaced the one inside their Open
MPI software.

Running an external VT install OMPI is a different thing; that's easy
enough to tell that someone is not using the included VT vs. an
external VT. But if the user is able to arbitrarily (and perhaps
accidentally) change the included VT, this becomes problematic for
support and maintenance.

> - about the two vampirtrace-specific spots in the .m4 files: they
> correspont
> to two tasks: firstly, decide if you want vampirtrace at all or (if
> you might
> want to update) and secondly, passing configure options to
> vampirtrace.
> we need to do the first before the second, of course. maybe we can
> move
> everything to "our" .m4 file, let me check ...

I would think that all OMPI-specific VT functionality should be in
one .m4 file. Per my other mail, I think it should be in contrib/vt/
configure.m4. This makes a nice, clean separation of m4
functionality and keeps it self-contained into the contrib/vt/ tree.

> - btw: so far the vampirtrace distribution tarball is brought to
> openmpi
> under ./tracing/vampirtrace with no modifications

Excellent. That makes things considerably easier.

> - the mpicc-vt (and friends) compiler wrappers: this is not part of
> vampirtrace but a new thing that only makes sense together with
> openmpi.
> therefore, they stay next to 'mpicc' and all others. in fact we're
> following
> a earlier suggestion from you, Jeff: 'mpicc-vt' is just like
> 'mpicc' but
> calls the 'vtcc' compier wrapper instead of 'cc'.
>
> this makes everything much simpler, because we can handle all
> special cases in
> vtcc. the wrapper config for 'mpicc-vt' is almost a mere copy of
> mpicc's one.
> therefore, I'd like to keep them where they are right now. is this
> o.k. with
> everyone?

I like the idea of mpicc-vt (etc.) wrappers, but again, I think they
should be consolidated in the contrib/vt tree. There's no technical
reason they need to be in the wrappers directory.

More specifically, I am uncomfortable with importing 3rd party
packages that touch a whole bunch of places in the OMPI tree. I am
much more comfortable with 3rd party packages being self-contained.

I hope to have the libnbc integration done either this week or next
as an example. We're still far enough away from v1.3 release that
this does not impact any release plans with VT.

-- 
Jeff Squyres
Cisco Systems