KR> # HG changeset patch
KR> # User Kaitlin Rupert <karupert(a)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(a)us.ibm.com