Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Edgar Gabriel (gabriel_at_[hidden])
Date: 2007-10-09 10:07:16

Jeff Squyres wrote:
> 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.

well, this issue could be however resolved, if ompi_info and friends
would have a way to report the precise version number for VT, isn't it?

Without having any strong feelings one way or the other, I think that
the functionality is great from the end-users perspective. Just my 0.02$...


> 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.

Edgar Gabriel
Assistant Professor
Parallel Software Technologies Lab
Department of Computer Science          University of Houston
Philip G. Hoffman Hall, Room 524        Houston, TX-77204, USA
Tel: +1 (713) 743-3857                  Fax: +1 (713) 743-3335