Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] RFC: Move of ompi_bitmap_t
From: Brian Barrett (brbarret_at_[hidden])
Date: 2009-01-30 15:11:16

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

   Brian Barrett
   Open MPI developer