
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

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@us.ibm.com
participants (2)
-
Dan Smith
-
Zhengang Li