Richard Graham wrote:
Let me start the e-mail conversation, and see how far we get.
Goal: The goal several of us have is to be able to use the btl’s
outside of the MPI layer in Open MPI. The layer itself is generic, w/o
specific knowledge of Upper Level Protocols, so is well suited for
this sort of use.
Technical Approach: What we have suggested is to start the process
with the Open MPI code base, and make it independent of the mpi-layer
(which it is now), and the run-time layer.
Before we get into any specific technical details,
the first question I have is are people totally opposed to the notion
of making the btl’s independent of MPI and the run-time ?
This does not mean that it can’t be used by it, but that there are
well defined abstraction layers, i.e., are people against the goal in
the first place ?
I am not against the idea of separating the BTLs out from OMPI. However,
it would help to know what we are really trying to accomplish this and
why using MPI is a non-starter. Is the issue to heavyweight of a
protocol or is it the infrastructure. I guess one question I have is if
we separate BTLs from OMPI do we lose valuable information needed to
establish and maintain the connections and could we run into some
chicken/egg problems. I assume the last issue is only of concern if we
remove the orte/opal dependencies.
What are alternative suggestions to the technical approach ?
The technical approach is really the implementation logistics, right?
That is how do we apply these changes to the trunk such that they get in
asap as to not require significant ongoing maintenance by the
implementors and not disturb the community members that are doing other
work.
Branch and patch - protects the community members the most until it
comes to the flag day of pushing the patch. But as you mention below
this has a heavy cost on the implementors and eventually a potentially
large blackout period.
Incremental approach - If we believe this project will be large I
success we try and map out all the different pieces and try and figure
out ways we can compartmentalize each piece such that they can be
putback separately from each other. This is similar to the branch and
patch approach except we try and do several patchs that each can be
reasonably tested and putback separate from the others. The hope is that
each patch is not that large and thus easier for the implementors to
maintain and merge. But this will require a more thought out plan as to
how things are done which might be detrimental to any agile development.
Scorched earth - Map a calendar time frame that we say from X to Y the
trunk will be under major renovation to move out the BTLs from OMPI.
This help the BTL movement developers but could put any other
development at risk. It also commits us completely to doing the BTL
separation so if things start falling a part it will definitely delay
the next release.
I personally prefer the Incremental Approach but we will need to have a
very well thought out plan to get this to work. This approach could
devolve into the other two approaches without careful planning, which I
don't believe anyone would really like to to see.
HTH,
--td
One suggestion has been to branch and patch. To me this is a long-term
maintenance nightmare.
What are peoples thoughts here ?
Rich
------------------------------------------------------------------------
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
