Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: Move of ompi_bitmap_t
From: Terry Dontje (Terry.Dontje_at_[hidden])
Date: 2009-01-30 15:23:41


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.

--td

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
> 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: keller_at_[hidden]
>> Oak Ridge, TN 37831-2008 AIM/Skype: rusraink
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>