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
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.
On Jul 19, 2008, at 9:34 AM, Aurélien Bouteiller wrote:
> 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 :]
> Le 18 juil. 08 à 09:51, Jeff Squyres a écrit :
>> WHAT: Add MCA base component parameter registration function
>> 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
> devel mailing list