I'm beginning to believe that we need a design meeting specifically
over this question. Too many unknowns exist, with significant
potential problems lurking behind them. Frankly, this issue could have
a major impact on how we operate, performance, and a variety of other
factors going forward - many of which may be difficult to predict.
I suspect there may not be "optimal" solutions to many of these
questions, but there certainly will be strong opinions in multiple
directions.
As part of that discussion, I propose that we consider alternative
methods for meeting the same overall objective - namely, reuse of the
BTL's by another software project. For example, a simple copy-and-
branch is the dominant method today, with patches used by both parties
to cherry-pick the changes they want from the other code users.
Multiple tools have been developed to support this mode of operation,
yet we haven't discussed any of them in this context. The proposed
approach contains a number of impacts that may be avoided with an
alternative approach.
Without such a meeting, I fear we are going to rapidly dissolve into
email hell again.
Ralph
On Dec 4, 2008, at 1:07 PM, Eugene Loh wrote:
Richard Graham wrote:
I expect this will involve some sort of well defined interface
between the btl’s and orte, and I don’t know if this will also
require something like this between the btl’s and the pml – I think
that interface is rigidly enforced, but am not sure.
I'm probably missing the scope of what you're saying here, but it
raises another question in my mind. Is there today a well-defined
interface between the BTLs and... anything else? PML or whatever?
Maybe this comes back to a documentation question: do we (or will
we) have anything written down that says what a BTL must do, what it
may rely on, etc.?
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
