KR> # HG changeset patch KR> # User Kaitlin Rupert <karupert@us.ibm.com> KR> # Date 1195605864 28800 KR> # Node ID 00a0b30a8d7b7d11ba03b0857962ac15b40868ed KR> # Parent 83aeadb6ebd9089e633013a0c65246a6d4881fcb KR> Add get_rasd_instance_from_ref() to RASD. KR> Updated get_rasd_instance_from_ref() to take an InstanceID KR> parameter. The original version used the InstanceID from the ref. KR> This was incorrect becasue the ref might not always have an KR> InstanceID or the InstanceID might not correspond to the KR> InstanceID of the RASD instance we want to return. Right, so... KR> +CMPIInstance *get_rasd_instance_from_ref(const CMPIContext *context, KR> + const CMPIObjectPath *ref, KR> + const char *id, KR> + const CMPIBroker *broker) KR> +{ KR> + CMPIStatus s = {CMPI_RC_OK, NULL}; KR> + CMPIInstance *inst = NULL; KR> + uint16_t type; KR> + KR> + if (rasd_type_from_classname(CLASSNAME(ref), &type) != CMPI_RC_OK) { KR> + cu_statusf(broker, &s, KR> + CMPI_RC_ERR_FAILED, KR> + "Unable to determine RASD type"); KR> + goto out; KR> + } Doesn't the same go for the type? If you are in VSSDC, say, then you have probably have a ref of root/virt:Xen_VSSDC.InstanceID="Xen:foo", which will not resolve to a valid type if you call rasd_type_from_classname() on it, as above. In most of our other external interfaces like this, we pass around a char *id and a uint16_t type, which is one of CIM_RASD_TYPE_*, per svpd_types.h. See Virt_DevicePool.h:get_pool_by_type() for example. KR> + inst = get_rasd_instance(context, ref, broker, id, type); Also, since we're not really getting the RASD information from the ref, I'm not sure the function is properly named, nor needed at this point. I think simply making the get_rasd_instance() non-static and exposed will do what we want, right? -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com