This should really be viewed as a code maintenance RFC. The reason this
came up in the first place is because we are investigating the btl move, but
these are really two very distinct issues. There are two bits of code that
have virtually the same functionality - they do have the same interface I am
told. The question is, is there a good reason to keep two different
versions in the repository ? Not knowing the history of why a second
version was created this is an inquiry. Is there some performance
advantage, or some other advantage to having these two versions ?
On 1/30/09 3:23 PM, "Terry D. Dontje" <Terry.Dontje_at_[hidden]> wrote:
> I second Brian's concern. So unless this is just an announcement that
> this is being done on a tmp branch only until everything is in order I
> think we need further discussions.
> Brian Barrett wrote:
>> 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
>> 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.
>>> 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
>>> One of the items is the ompi_bitmap_t which is quite similar to the
>>> The question is, whether we can remove favoring a solution just in opal.
>>> 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
>>> 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
>>> 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: keller_at_[hidden]
>>> Oak Ridge, TN 37831-2008 AIM/Skype: rusraink
>>> devel mailing list
> devel mailing list