So once again, I bring up my objection of this entire line of moving until such time as the entire process is properly mapped out. I believe it's premature to being moving around code in preparation for a move that hasn't been proven viable yet. Until there is concrete evidence that such a move is possible, won't degrade application performance, and does not make the code totally unmaintainable, I believe that any related code changes should not be brought into the trunk.

Brian


On Jan 30, 2009, at 12:30 PM, Rainer Keller wrote:

On behalf of Laurent Broto

RFC: Move of ompi_bitmap_t

WHAT: Move ompi_bitmap_t into opal or onet-layer

WHY: Remove dependency on ompi-layer.

WHERE: ompi/class

WHEN: Open MPI-1.4

TIMEOUT: February 3, 2009.

-------------------------------------
Details:
WHY:
The ompi_bitmap_t is being used in various places within opal/orte/ ompi. With the proposed splitting of BTLs into a separate library, we are currently investigating several of the differences between ompi/class/* and opal/class/*

One of the items is the ompi_bitmap_t which is quite similar to the
opal_bitmap_t.
The question is, whether we can remove favoring a solution just in opal.

WHAT:
The data structures in the opal-version are the same,
so is the interface,
the implementation is *almost* the same....

The difference is the Fortran handles ;-]!

Maybe we're missing something but could we have a discussion, on why Fortran sizes are playing a role here, and if this is a hard requirement, how we could settle that into that current interface (possibly without a notion of Fortran,
but rather, set some upper limit that the bitmap may grow to?)

With best regards,
Laurent and Rainer
--
------------------------------------------------------------------------
Rainer Keller, PhD                  Tel: (865) 241-6293
Oak Ridge National Lab          Fax: (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


--
  Brian Barrett
  Open MPI developer
  http://www.open-mpi.org/


Reply via email to