Dan,
I got this when writing the resource setting data related method test
case for VSMS.
In DMTF cimv216Experimental, we have:
uint32 AddResourceSettings(CIM_VSSD REF AffectedConfiguration,
string ResourceSettings[],
CIM_RASD REF ResultingResourceSettings[], /* out */
CIM_ConcreteJob REF Job); /* out */
uint32 RemoveResourceSettings(CIM_RASD REF ResourceSettings[],
CIM_ConcreteJob REF Job); /* out */
But in the VSMS provider, the handlers are defined as follows:
static struct method_handler AddResourceSettings = {
.name = "AddResourceSettings",
.handler = add_resource_settings,
.args = {{"AffectedConfiguration", CMPI_string}, /* dmtf
mof says CMPI_ref here */
{"ResourceSettings", CMPI_stringA},
ARG_END
}
};
static struct method_handler RemoveResourceSettings = {
.name = "RemoveResourceSettings",
.handler = rm_resource_settings,
.args = {{"ResourceSettings", CMPI_stringA}, /* dmtf mof
says CMPI_refA here */
ARG_END
}
};
And the three add/modify/remove resource settings method handler are
using the same
helper function 'update_resource_settings' taking ResourceSettings as
embedded instance
string array.
I think we need some code refactoring here for the three method handlers.
--
- Zhengang
Show replies by date
ZL> And the three add/modify/remove resource settings method handler
ZL> are using the same helper function 'update_resource_settings'
ZL> taking ResourceSettings as embedded instance string array.
Are you specifically noting that we don't return a Job? The
std_invokemethod handler specification doesn't take outgoing
parameters into account, so those shouldn't be specified there.
Further, we make these changes synchronously, so we don't need to
return a job in any of these cases.
The CMPI_stringA type is used right now because we're not testing on a
EO-enabled CIMOM, which means the embedded instance comes to us as a
string (or string array, depending), which we must parse ourselves.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com