Jeff is referring to changes made over a year and a half ago when the
checkpoint/restart work came into the trunk. This was a change in
component_base_data_t from using a 'bool checkpointable' to a
bitfield that can encode many more options (FT related and otherwise)
for component metadata.
The other change was adding a 'query' function for mca_base_select to
the mca_base_componet structure. This is not FT related, but general
code cleanup.
Both of these changes require the versions of these data structures
to be incremented. There was an RFC that went across devel-core with
the subject "RFC: MCA Base Component Version Change" with more details.
So in short there is nothing new happening with these structures as a
result of the meeting, just that the structure has changed since v1.2.
-- Josh
On Jul 19, 2008, at 9:34 AM, Aurélien Bouteiller wrote:
Jeff,
What modifications are taking place in the mca_base_component_t for
FT purposes ? I don't remember talking about this particular point
during the meeting. I'm Just curious :]
Aurelien
Le 18 juil. 08 à 09:51, Jeff Squyres a écrit :
WHAT: Add MCA base component parameter registration function
WHY:
a) The component "open" function has been overloaded as the MCA
component parameter registration function; we've long talked about
fixing this
b) mca_base_component_t is already changing for v1.3 for the FT
stuff; since this is the core struct for *all* components, it
would be good to change this struct *once* (vs. once for v1.3 and
then again for v1.4)
WHERE: mca.h, the MCA base component open functions, and at least
1 or 2 components for testing purposes
WHEN: before v1.3
TIMEOUT: Friday, 25 July 2008
-------------------------------------
We've long-since talked about how the MCA component "open"
function was incorrectly overloaded to be components' MCA
parameter registration functions. We've also long-since talked
about splitting "open" into two functions: the [real] open
function, and the component MCA parameter registration function.
Such a change, for example, would allow ompi_info to only call the
parameter registration function -- not the open function (because
open is allowed to reserve resources).
For v1.3, we propose adding this registration function to
mca_base_component_t and converting a small number of components
to use it (just for testing purposes). The main idea here is that
the mca_base_component_t struct stuff already changed for v1.3 for
FT stuff; it would be good to get in all foreseeable changes for
v1.3 so that we don't have to change it again for v1.4.
Specifically: we know we want the MCA param registration function
split out, so let's add that function for v1.3 and make it
backwards compatible (e.g., call both the registration and open
functions if they are !=NULL). For v1.4, do a full-scale
conversion of all components and make ompi_info properly take
advantage of the new parameter registration function.
--
Jeff Squyres
Cisco Systems
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
