Just to throw some $0.002 into this overall discussion...
Not knowing this was going to be happening, I was actually about to
propose moving the opal/util/arch.c code back to the ompi layer. The
original move had caused quite a bit of angst due to the fortran
stuff. Originally, I had needed to make the move because the design
for modex-less operations needed to know the architecture prior to
launching the app. However, as things evolved, it turns out that this
isn't necessary at all - in fact, the launch system doesn't actually
take advantage of the ORTE layer knowing the arch.
So from the point of view of the current system, there is no value in
having the opal/util/arch.c code - it can be restored to the original
datatype area.
I realize that Rainer is pursuing a different objective, and that's
fine. My point here is that the original motivation for breaking the
abstraction barrier no longer exists, so whatever we do here is free
to reflect that change in requirement.
I would personally like to see OPAL retain its original objective and
avoid having Fortran knowledge down there.
Ralph
On Jun 1, 2009, at 3:02 PM, Rainer Keller wrote:
Thanks, Jeff!
On Monday 01 June 2009 04:53:19 pm Jeff Squyres wrote:
Per the MPI_Flogical issue -- I think Rainer just exposed some old
ugliness. We've apparently had MPI_Flogical defined in
ompi_config.h.in for a long, long time -- we used it in some places
and used ompi_fortran_logical_t in other places.
Even though I *may* be responsible for this particular bit of
ugliness
way back in the past :-), I think the #define for MPI_Flogical should
be removed if for no other reason than 6-12 months from now when
someone else re-discovers it, they'll have to go lookup to see if
it's
a real MPI type -- which it's not. Even though it's longer, we
should
use ompi_fortran_logical_t everywhere.
My $0.02.
On Jun 1, 2009, at 1:23 PM, Brian W. Barrett wrote:
Well, this may just be another sign that the push of the DDT to OPAL
is a
bad idea. That's been my opinion from the start, so I'm biased.
But OPAL
was intended to be single process systems portability, not MPI crud.
Brian
On Mon, 1 Jun 2009, Rainer Keller wrote:
Hmm, OK, I see.
However, I do see potentially a problem with work getting ddt on
the OPAL
layer when we do have a fortran compiler with different alignment
requirements
for the same-sized basic types...
As far as I understand the OPAL layer to abstract away from
underlying system
portability, libc-quirks, and compiler information.
But I am perfectly fine with reverting this!
Let's discuss, maybe phone?
Thanks,
Rainer
On Monday 01 June 2009 10:38:51 am Jeff Squyres wrote:
Hmm. I'm not sure that I like this commit.
George, Brian, and I specifically kept Fortran out of (the non-
generated code in) opal because the MPI layer is the *only* layer
that
uses Fortran. There was one or two minor abstraction breaks (you
cited opal/util/arch.c), but now we have Fortran all throughout
Opal.
Hmmm... :-\
Is MPI_Flogical a real type? I don't see it defined in the
MPI-2.2
latex sources, but I could be missing it. I *thought* we used
ompi_fortran_logical_t internally because there was no officially
sanctioned MPI_<foo> type for it...?
--
------------------------------------------------------------------------
Rainer Keller, PhD Tel: +1 (865) 241-6293
Oak Ridge National Lab Fax: +1 (865) 241-4811
PO Box 2008 MS 6164 Email: kel...@ornl.gov
Oak Ridge, TN 37831-2008 AIM/Skype: rusraink
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
