[PATCH 00 of 12] #1 - Adoption of changes to std_assoc struct in std_association for all associations
This is the follow up patch to the API changes made in std_association. The struct std_assoc does now take lists for source, target and assoc classnames.
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196333528 -3600 # Node ID af7ce48b18bed937d49df9d4073cac564c391971 # Parent c478a5b30689a80159588c8f914ac97263694372 ECTP: Adoption of changes to std_assoc struct in std_association This is the follow up patch to the API changes made in std_association. The struct std_assoc does now take lists for source, target and assoc classnames. It also adds the registration of ComputerSystem and HostSystem to the interop namespace. This is necessary to check the client's resultClass value. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r c478a5b30689 -r af7ce48b18be Makefile.am --- a/Makefile.am Wed Nov 28 11:06:22 2007 -0800 +++ b/Makefile.am Thu Nov 29 11:52:08 2007 +0100 @@ -36,6 +36,8 @@ MOFS = \ schema/ElementSettingData.mof INTEROP_MOFS = \ + schema/ComputerSystem.mof \ + schema/HostSystem.mof \ schema/RegisteredProfile.mof \ schema/ElementConformsToProfile.mof diff -r c478a5b30689 -r af7ce48b18be src/Virt_ElementConformsToProfile.c --- a/src/Virt_ElementConformsToProfile.c Wed Nov 28 11:06:22 2007 -0800 +++ b/src/Virt_ElementConformsToProfile.c Thu Nov 29 11:52:08 2007 +0100 @@ -222,27 +222,47 @@ static CMPIInstance *make_ref(const CMPI return assoc_inst; } +char* conformant_standard[] = { + "Xen_RegisteredProfile", + "KVM_RegisteredProfile", + NULL +}; + +char* managed_element[] = { + "Xen_HostSystem", + "Xen_ComputerSystem", + "KVM_HostSystem", + "KVM_ComputerSystem", + NULL +}; + +char* assoc_classname[] = { + "Xen_ElementConformsToProfile", + "KVM_ElementConformsToProfile", + NULL +}; + struct std_assoc forward = { - .source_class = "CIM_RegisteredProfile", + .source_class = (char**)&conformant_standard, .source_prop = "ConformantStandard", - .target_class = "CIM_ManagedElement", + .target_class = (char**)&managed_element, .target_prop = "ManagedElement", - .assoc_class = NULL, + .assoc_class = (char**)&assoc_classname, .handler = prof_to_elem, .make_ref = make_ref }; struct std_assoc backward = { - .source_class = "CIM_ManagedElement", + .source_class = (char**)&managed_element, .source_prop = "ManagedElement", - .target_class = "CIM_RegisteredProfile", + .target_class = (char**)&conformant_standard, .target_prop = "ConformantStandard", - .assoc_class = NULL, + .assoc_class = (char**)&assoc_classname, .handler = elem_to_prof, .make_ref = make_ref @@ -253,7 +273,6 @@ struct std_assoc *assoc_handlers[] = { &backward, NULL }; - STDA_AssocMIStub(, Virt_ElementConformsToProfileProvider, _BROKER, libvirt_cim_init(), assoc_handlers); /*
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196334170 -3600 # Node ID d8dbe141c0b4a99c4ee0d380c8bcfe6abb6d8d66 # Parent af7ce48b18bed937d49df9d4073cac564c391971 EAFP: Adoption of changes to std_assoc struct in std_association This is the follow up patch to the API changes made in std_association. The struct std_assoc does now take lists for source, target and assoc classnames. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r af7ce48b18be -r d8dbe141c0b4 src/Virt_ElementAllocatedFromPool.c --- a/src/Virt_ElementAllocatedFromPool.c Thu Nov 29 11:52:08 2007 +0100 +++ b/src/Virt_ElementAllocatedFromPool.c Thu Nov 29 12:02:50 2007 +0100 @@ -264,23 +264,57 @@ static CMPIInstance *make_ref(const CMPI return refinst; } +char* antecedent[] = { + "Xen_ProcessorPool", + "Xen_MemoryPool", + "Xen_NetworkPool", + "Xen_DiskPool", + "KVM_ProcessorPool", + "KVM_MemoryPool", + "KVM_NetworkPool", + "KVM_DiskPool", + NULL +}; + +char* dependent[] = { + "Xen_Processor", + "Xen_Memory", + "Xen_Network", + "Xen_Disk", + "KVM_Processor", + "KVM_Memory", + "KVM_Network", + "KVM_Disk", + NULL +}; + +char* assoc_classname[] = { + "Xen_ElementAllocatedFromPool", + "KVM_ElementAllocatedFromPool", + NULL +}; + static struct std_assoc _vdev_to_pool = { - .source_class = "CIM_LogicalDevice", + .source_class = (char**)&dependent, .source_prop = "Dependent", - .target_class = "CIM_ResourcePool", + .target_class = (char**)&antecedent, .target_prop = "Antecedent", + + .assoc_class = (char**)&assoc_classname, .handler = vdev_to_pool, .make_ref = make_ref }; static struct std_assoc _pool_to_vdev = { - .source_class = "CIM_ResourcePool", + .source_class = (char**)&antecedent, .source_prop = "Antecedent", - .target_class = "CIM_LogicalDevice", + .target_class = (char**)&dependent, .target_prop = "Dependent", + + .assoc_class = (char**)&assoc_classname, .handler = pool_to_vdev, .make_ref = make_ref
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196338264 -3600 # Node ID 38068b513857c8cb64a3f5c808f0bd42e272dfb9 # Parent d8dbe141c0b4a99c4ee0d380c8bcfe6abb6d8d66 EC: Adoption of changes to std_assoc struct in std_association This is the follow up patch to the API changes made in std_association. The struct std_assoc does now take lists for source, target and assoc classnames. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r d8dbe141c0b4 -r 38068b513857 src/Virt_ElementCapabilities.c --- a/src/Virt_ElementCapabilities.c Thu Nov 29 12:02:50 2007 +0100 +++ b/src/Virt_ElementCapabilities.c Thu Nov 29 13:11:04 2007 +0100 @@ -237,21 +237,23 @@ static CMPIStatus pool_to_alloc(const CM out: return s; } + static CMPIInstance *make_ref(const CMPIObjectPath *ref, const CMPIInstance *inst, struct std_assoc_info *info, struct std_assoc *assoc) { - CMPIInstance *refinst; - char *base; - - base = class_base_name(assoc->assoc_class); - if (base == NULL) + CMPIStatus s = {CMPI_RC_OK, NULL}; + CMPIInstance *refinst = NULL; + virConnectPtr conn = NULL; + + conn = connect_by_classname(_BROKER, CLASSNAME(ref), &s); + if (conn == NULL) return NULL; refinst = get_typed_instance(_BROKER, - CLASSNAME(ref), - base, + pfx_from_conn(conn), + "ElementCapabilities", NAMESPACE(ref)); if (refinst != NULL) { @@ -265,109 +267,146 @@ static CMPIInstance *make_ref(const CMPI (CMPIValue *)&instop, CMPI_ref); } - free(base); + virConnectClose(conn); return refinst; } +char* assoc_classname[] = { + "Xen_ElementCapabilities", + "KVM_ElementCapabilities", + NULL +}; + +char* host_system[] = { + "Xen_HostSystem", + "KVM_HostSystem", + NULL +}; + +char* virtual_system_management_capabilities[] = { + "Xen_VirtualSystemManagementCapabilities", + "KVM_VirtualSystemManagementCapabilities", + NULL +}; + struct std_assoc system_to_vsm_cap = { - .source_class = "CIM_System", + .source_class = (char**)&host_system, .source_prop = "ManagedElement", - .target_class = "CIM_VirtualSystemManagementCapabilities", + .target_class = (char**)&virtual_system_management_capabilities, .target_prop = "Capabilities", - .assoc_class = "CIM_ElementCapabilities", + .assoc_class = (char**)&assoc_classname, .handler = sys_to_cap, .make_ref = make_ref }; struct std_assoc vsm_cap_to_system = { - .source_class = "CIM_VirtualSystemManagementCapabilities", + .source_class = (char**)&virtual_system_management_capabilities, .source_prop = "Capabilities", - .target_class = "CIM_System", + .target_class = (char**)&host_system, .target_prop = "ManagedElement", - .assoc_class = "CIM_ElementCapabilities", + .assoc_class = (char**)&assoc_classname, .handler = cap_to_sys, .make_ref = make_ref }; -struct std_assoc xen_cs_to_ele_cap = { - .source_class = "Xen_ComputerSystem", +char* computer_system[] = { + "Xen_ComputerSystem", + "KVM_ComputerSystem", + NULL +}; + +char* enabled_logical_element_capabilities[] = { + "Xen_EnabledLogicalElementCapabilities", + "KVM_EnabledLogicalElementCapabilities", + NULL +}; + +struct std_assoc ele_cap_to_cs = { + .source_class = (char**)&enabled_logical_element_capabilities, + .source_prop = "Capabilities", + + .target_class = (char**)&computer_system, + .target_prop = "ManagedElement", + + .assoc_class = (char**)&assoc_classname, + + .handler = cap_to_cs, + .make_ref = make_ref +}; + +struct std_assoc cs_to_ele_cap = { + .source_class = (char**)&computer_system, .source_prop = "ManagedElement", - .target_class = "CIM_EnabledLogicalElementCapabilities", + .target_class = (char**)&enabled_logical_element_capabilities, .target_prop = "Capabilities", - .assoc_class = "CIM_ElementCapabilities", + .assoc_class = (char**)&assoc_classname, .handler = cs_to_cap, .make_ref = make_ref }; -struct std_assoc kvm_cs_to_ele_cap = { - .source_class = "KVM_ComputerSystem", +char* allocation_capabilities[] = { + "Xen_AllocationCapabilities", + "KVM_AllocationCapabilities", + NULL +}; + +char* resource_pool[] = { + "Xen_ProcessorPool", + "Xen_MemoryPool", + "Xen_NetworkPool", + "Xen_DiskPool", + "KVM_ProcessorPool", + "KVM_MemoryPool", + "KVM_NetworkPool", + "KVM_DiskPool", + NULL +}; + +struct std_assoc alloc_cap_to_resource_pool = { + .source_class = (char**)&allocation_capabilities, + .source_prop = "Capabilities", + + .target_class = (char**)&resource_pool, + .target_prop = "ManagedElement", + + .assoc_class = (char**)&assoc_classname, + + .handler = alloc_to_pool, + .make_ref = make_ref +}; + +struct std_assoc resource_pool_to_alloc_cap = { + .source_class = (char**)&resource_pool, .source_prop = "ManagedElement", - .target_class = "CIM_EnabledLogicalElementCapabilities", + .target_class = (char**)&allocation_capabilities, .target_prop = "Capabilities", - .assoc_class = "CIM_ElementCapabilities", - - .handler = cs_to_cap, - .make_ref = make_ref -}; - -struct std_assoc ele_cap_to_computer_system = { - .source_class = "CIM_EnabledLogicalElementCapabilities", - .source_prop = "Capabilities", - - .target_class = "CIM_ComputerSystem", - .target_prop = "ManagedElement", - - .assoc_class = "CIM_ElementCapabilities", - - .handler = cap_to_cs, - .make_ref = make_ref -}; - -struct std_assoc alloc_cap_to_resource_pool = { - .source_class = "CIM_AllocationCapabilities", - .source_prop = "Capabilities", - - .target_class = "CIM_ResourcePool", - .target_prop = "ManagedElement", - - .handler = alloc_to_pool, - .make_ref = make_ref -}; - -struct std_assoc resource_pool_to_alloc_cap = { - .source_class = "CIM_ResourcePool", - .source_prop = "ManagedElement", - - .target_class = "CIM_AllocationCapabilities", - .target_prop = "Capabilities", + .assoc_class = (char**)&assoc_classname, .handler = pool_to_alloc, .make_ref = make_ref }; struct std_assoc *assoc_handlers[] = { - &xen_cs_to_ele_cap, - &kvm_cs_to_ele_cap, &system_to_vsm_cap, &vsm_cap_to_system, - &ele_cap_to_computer_system, + &ele_cap_to_cs, + &cs_to_ele_cap, &alloc_cap_to_resource_pool, &resource_pool_to_alloc_cap, NULL }; - STDA_AssocMIStub(, Xen_ElementCapabilitiesProvider, _BROKER, libvirt_cim_init(), assoc_handlers); STDA_AssocMIStub(, KVM_ElementCapabilitiesProvider, _BROKER, libvirt_cim_init(), assoc_handlers);
HE> --- a/src/Virt_ElementCapabilities.c Thu Nov 29 12:02:50 2007 +0100 HE> +++ b/src/Virt_ElementCapabilities.c Thu Nov 29 13:11:04 2007 +0100 HE> @@ -237,21 +237,23 @@ static CMPIStatus pool_to_alloc(const CM HE> out: HE> return s; HE> } HE> + HE> static CMPIInstance *make_ref(const CMPIObjectPath *ref, HE> const CMPIInstance *inst, HE> struct std_assoc_info *info, HE> struct std_assoc *assoc) HE> { HE> - CMPIInstance *refinst; HE> - char *base; HE> - HE> - base = class_base_name(assoc->assoc_class); HE> - if (base == NULL) HE> + CMPIStatus s = {CMPI_RC_OK, NULL}; HE> + CMPIInstance *refinst = NULL; HE> + virConnectPtr conn = NULL; HE> + HE> + conn = connect_by_classname(_BROKER, CLASSNAME(ref), &s); HE> + if (conn == NULL) HE> return NULL; HE> refinst = get_typed_instance(_BROKER, HE> - CLASSNAME(ref), HE> - base, HE> + pfx_from_conn(conn), HE> + "ElementCapabilities", HE> NAMESPACE(ref)); HE> if (refinst != NULL) { HE> @@ -265,109 +267,146 @@ static CMPIInstance *make_ref(const CMPI HE> (CMPIValue *)&instop, CMPI_ref); HE> } HE> - free(base); HE> + virConnectClose(conn); HE> return refinst; HE> } Hmm, are either of these hunks related to the API change? -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Dan Smith wrote:
Hmm, are either of these hunks related to the API change? In general yes and no: yes - because the code does not get compiled without changing the make_ref() function. no - as this update also needs to be done to some other associations, who's make_ref() hasn't been affected by the changes to the API. So I decided to fix where necessary and added a ToDo for the other associations. Hope this is ok for this time ?
-- Regards Heidi Eckhart Software Engineer Linux Technology Center - Open Hypervisor heidieck@linux.vnet.ibm.com ************************************************** IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Herbert Kircher Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196339009 -3600 # Node ID 36e16117e8b18e85a4898879091b919074dc44dc # Parent 38068b513857c8cb64a3f5c808f0bd42e272dfb9 ESD: Adoption of changes to std_assoc struct in std_association This is the follow up patch to the API changes made in std_association. The struct std_assoc does now take lists for source, target and assoc classnames. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 38068b513857 -r 36e16117e8b1 src/Virt_ElementSettingData.c --- a/src/Virt_ElementSettingData.c Thu Nov 29 13:11:04 2007 +0100 +++ b/src/Virt_ElementSettingData.c Thu Nov 29 13:23:29 2007 +0100 @@ -129,17 +129,18 @@ static CMPIInstance *make_ref(const CMPI struct std_assoc_info *info, struct std_assoc *assoc) { + CMPIStatus s = {CMPI_RC_OK, NULL}; CMPIInstance *refinst = NULL; - char *base; + virConnectPtr conn = NULL; uint16_t prop_value = 1; - base = class_base_name(assoc->assoc_class); - if (base == NULL) - goto out; + conn = connect_by_classname(_BROKER, CLASSNAME(ref), &s); + if (conn == NULL) + return NULL; refinst = get_typed_instance(_BROKER, - CLASSNAME(ref), - base, + pfx_from_conn(conn), + "ElementSettingData", NAMESPACE(ref)); if (refinst != NULL) { @@ -165,33 +166,55 @@ static CMPIInstance *make_ref(const CMPI (CMPIValue *)&prop_value, CMPI_uint16); } -out: - free(base); + virConnectClose(conn); return refinst; } +char* virtual_system_setting_data[] = { + "Xen_VirtualSystemSettingData", + "KVM_VirtualSystemSettingData", + NULL +}; + +char* resource_allocation_setting_data[] = { + "Xen_ResourceAllocationSettingData", + "KVM_ResourceAllocationSettingData", + NULL +}; + +char* managed_element[] = { + "CIM_ManagedElement", + NULL +}; + +char* assoc_classname[] = { + "Xen_ElementSettingData", + "KVM_ElementSettingData", + NULL +}; + static struct std_assoc _vssd_to_vssd = { - .source_class = "CIM_VirtualSystemSettingData", + .source_class = (char**)&virtual_system_setting_data, .source_prop = "ManagedElement", - .target_class = "CIM_ManagedElement", + .target_class = (char**)&managed_element, .target_prop = "SettingData", - .assoc_class = "CIM_ElementSettingData", + .assoc_class = (char**)&assoc_classname, .handler = vssd_to_vssd, .make_ref = make_ref }; static struct std_assoc _rasd_to_rasd = { - .source_class = "CIM_ResourceAllocationSettingData", + .source_class = (char**)&resource_allocation_setting_data, .source_prop = "ManagedElement", - .target_class = "CIM_ManagedElement", + .target_class = (char**)&managed_element, .target_prop = "SettingData", - .assoc_class = "CIM_ElementSettingData", + .assoc_class = (char**)&assoc_classname, .handler = rasd_to_rasd, .make_ref = make_ref
Heidi Eckhart wrote:
@@ -129,17 +129,18 @@ static CMPIInstance *make_ref(const CMPI struct std_assoc_info *info, struct std_assoc *assoc) { + CMPIStatus s = {CMPI_RC_OK, NULL}; CMPIInstance *refinst = NULL; - char *base; + virConnectPtr conn = NULL; uint16_t prop_value = 1;
- base = class_base_name(assoc->assoc_class); - if (base == NULL) - goto out; + conn = connect_by_classname(_BROKER, CLASSNAME(ref), &s); + if (conn == NULL) + return NULL;
refinst = get_typed_instance(_BROKER, - CLASSNAME(ref), - base, + pfx_from_conn(conn), + "ElementSettingData", NAMESPACE(ref));
if (refinst != NULL) { @@ -165,33 +166,55 @@ static CMPIInstance *make_ref(const CMPI (CMPIValue *)&prop_value, CMPI_uint16); }
-out: - free(base); + virConnectClose(conn);
return refinst; }
Could this too be in a separate patch? =) -- Kaitlin Rupert IBM Linux Technology Center karupert@us.ibm.com
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196339320 -3600 # Node ID 69f4e34c1187ac9013cf779f78c2831544b4a5a4 # Parent 36e16117e8b18e85a4898879091b919074dc44dc HD: Adoption of changes to std_assoc struct in std_association This is the follow up patch to the API changes made in std_association. The struct std_assoc does now take lists for source, target and assoc classnames. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 36e16117e8b1 -r 69f4e34c1187 src/Virt_HostedDependency.c --- a/src/Virt_HostedDependency.c Thu Nov 29 13:23:29 2007 +0100 +++ b/src/Virt_HostedDependency.c Thu Nov 29 13:28:40 2007 +0100 @@ -99,55 +99,54 @@ static CMPIInstance *make_ref(const CMPI return refinst; } -static struct std_assoc xen_vs_to_host = { - .source_class = "Xen_ComputerSystem", +char* antecedent[] = { + "Xen_ComputerSystem", + "KVM_ComputerSystem", + NULL +}; + +char* dependent[] = { + "Xen_HostSystem", + "KVM_HostSystem", + NULL +}; + +char* assoc_classname[] = { + "Xen_HostedDependency", + "KVM_HostedDependency", + NULL +}; + +static struct std_assoc _vs_to_host = { + .source_class = (char**)&antecedent, .source_prop = "Antecedent", - .target_class = "Xen_HostSystem", - .source_prop = "Dependent", + .target_class = (char**)&dependent, + .target_prop = "Dependent", + + .assoc_class = (char**)&assoc_classname, .handler = vs_to_host, .make_ref = make_ref }; -static struct std_assoc kvm_vs_to_host = { - .source_class = "KVM_ComputerSystem", - .source_prop = "Antecedent", - - .target_class = "KVM_HostSystem", +static struct std_assoc _host_to_vs = { + .source_class = (char**)&dependent, .source_prop = "Dependent", - .handler = vs_to_host, - .make_ref = make_ref -}; + .target_class = (char**)&antecedent, + .target_prop = "Antecedent", -static struct std_assoc xen_host_to_vs = { - .source_class = "Xen_HostSystem", - .source_prop = "Dependent", - - .target_class = "Xen_ComputerSystem", - .target_prop = "Antecedent", + .assoc_class = (char**)&assoc_classname, .handler = host_to_vs, .make_ref = make_ref }; -static struct std_assoc kvm_host_to_vs = { - .source_class = "KVM_HostSystem", - .source_prop = "Dependent", - - .target_class = "KVM_ComputerSystem", - .target_prop = "Antecedent", - - .handler = host_to_vs, - .make_ref = make_ref -}; static struct std_assoc *handlers[] = { - &xen_vs_to_host, - &xen_host_to_vs, - &kvm_vs_to_host, - &kvm_host_to_vs, + &_vs_to_host, + &_host_to_vs, NULL };
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196339597 -3600 # Node ID 8a75970ed83c888e50b7b83360078c8ab32316db # Parent 69f4e34c1187ac9013cf779f78c2831544b4a5a4 HRP: Adoption of changes to std_assoc struct in std_association This is the follow up patch to the API changes made in std_association. The struct std_assoc does now take lists for source, target and assoc classnames. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 69f4e34c1187 -r 8a75970ed83c src/Virt_HostedResourcePool.c --- a/src/Virt_HostedResourcePool.c Thu Nov 29 13:28:40 2007 +0100 +++ b/src/Virt_HostedResourcePool.c Thu Nov 29 13:33:17 2007 +0100 @@ -119,27 +119,51 @@ static CMPIInstance *make_ref(const CMPI return refinst; } +char* group_component[] = { + "Xen_HostSystem", + "KVM_HostSystem", + NULL +}; + +char* part_component[] = { + "Xen_ProcessorPool", + "Xen_MemoryPool", + "Xen_NetworkPool", + "Xen_DiskPool", + "KVM_ProcessorPool", + "KVM_MemoryPool", + "KVM_NetworkPool", + "KVM_DiskPool", + NULL +}; + +char* assoc_classname[] = { + "Xen_HostedResourcePool", + "KVM_HostedResourcePool", + NULL +}; + struct std_assoc forward = { - .source_class = "CIM_ResourcePool", + .source_class = (char**)&part_component, .source_prop = "PartComponent", - .target_class = "CIM_System", + .target_class = (char**)&group_component, .target_prop = "GroupComponent", - .assoc_class = NULL, + .assoc_class = (char**)&assoc_classname, .handler = pool_to_sys, .make_ref = make_ref }; struct std_assoc backward = { - .source_class = "CIM_System", + .source_class = (char**)&group_component, .source_prop = "GroupComponent", - .target_class = "CIM_ResourcePool", + .target_class = (char**)&part_component, .target_prop = "PartComponent", - .assoc_class = NULL, + .assoc_class = (char**)&assoc_classname, .handler = sys_to_pool, .make_ref = make_ref
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196340080 -3600 # Node ID 0f6cf316d454a485c3cc965305dd353664873d1f # Parent 8a75970ed83c888e50b7b83360078c8ab32316db HS: Adoption of changes to std_assoc struct in std_association This is the follow up patch to the API changes made in std_association. The struct std_assoc does now take lists for source, target and assoc classnames. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 8a75970ed83c -r 0f6cf316d454 src/Virt_HostedService.c --- a/src/Virt_HostedService.c Thu Nov 29 13:33:17 2007 +0100 +++ b/src/Virt_HostedService.c Thu Nov 29 13:41:20 2007 +0100 @@ -81,16 +81,17 @@ static CMPIInstance *make_ref(const CMPI struct std_assoc_info *info, struct std_assoc *assoc) { + CMPIStatus s = {CMPI_RC_OK, NULL}; CMPIInstance *refinst = NULL; - char *base; + virConnectPtr conn = NULL; - base = class_base_name(assoc->assoc_class); - if (base == NULL) - goto out; + conn = connect_by_classname(_BROKER, CLASSNAME(ref), &s); + if (conn == NULL) + return NULL; refinst = get_typed_instance(_BROKER, - CLASSNAME(ref), - base, + pfx_from_conn(conn), + "HostedService", NAMESPACE(ref)); if (refinst != NULL) { @@ -101,67 +102,58 @@ static CMPIInstance *make_ref(const CMPI set_reference(assoc, refinst, ref, instop); } -out: + virConnectClose(conn); + return refinst; } -static struct std_assoc xen_host_to_service = { - .source_class = "Xen_HostSystem", +char* antecedent[] = { + "Xen_HostSystem", + "KVM_HostSystem", + NULL +}; + +char* dependent[] = { + "Xen_VirtualSystemManagementService", + "KVM_VirtualSystemManagementService", + NULL +}; + +char* assoc_classname[] = { + "Xen_HostedService", + "KVM_HostedService", + NULL +}; + +static struct std_assoc _host_to_service = { + .source_class = (char**)&antecedent, .source_prop = "Antecedent", - .target_class = "CIM_ManagedElement", + .target_class = (char**)&dependent, .target_prop = "Dependent", - .assoc_class = "CIM_HostedService", + .assoc_class = (char**)&assoc_classname, .handler = host_to_service, .make_ref = make_ref }; -static struct std_assoc xen_service_to_host = { - .source_class = "CIM_Service", +static struct std_assoc _service_to_host = { + .source_class = (char**)&dependent, .source_prop = "Dependent", - - .target_class = "CIM_ManagedElement", + + .target_class = (char**)&antecedent, .target_prop = "Antecedent", - .assoc_class = "CIM_HostedService", - - .handler = service_to_host, - .make_ref = make_ref -}; - -static struct std_assoc kvm_host_to_service = { - .source_class = "KVM_HostSystem", - .source_prop = "Antecedent", - - .target_class = "CIM_Service", - .target_prop = "Dependent", - - .assoc_class = "CIM_HostedService", - - .handler = host_to_service, - .make_ref = make_ref -}; - -static struct std_assoc kvm_service_to_host = { - .source_class = "CIM_Service", - .source_prop = "Dependent", - - .target_class = "KVM_ComputerSystem", - .target_prop = "Antecedent", - - .assoc_class = "CIM_HostedService", - + .assoc_class = (char**)&assoc_classname, + .handler = service_to_host, .make_ref = make_ref }; static struct std_assoc *handlers[] = { - &xen_host_to_service, - &xen_service_to_host, - &kvm_host_to_service, - &kvm_service_to_host, + &_host_to_service, + &_service_to_host, NULL };
Heidi Eckhart wrote:
+ CMPIStatus s = {CMPI_RC_OK, NULL}; CMPIInstance *refinst = NULL; - char *base; + virConnectPtr conn = NULL;
- base = class_base_name(assoc->assoc_class); - if (base == NULL) - goto out; + conn = connect_by_classname(_BROKER, CLASSNAME(ref), &s); + if (conn == NULL) + return NULL;
refinst = get_typed_instance(_BROKER, - CLASSNAME(ref), - base, + pfx_from_conn(conn), + "HostedService", NAMESPACE(ref));
if (refinst != NULL) { @@ -101,67 +102,58 @@ static CMPIInstance *make_ref(const CMPI set_reference(assoc, refinst, ref, instop); }
-out: + virConnectClose(conn); + return refinst;
I think this patch has some unrelated changes. Could this be sent as a separate patch?
+char* dependent[] = { + "Xen_VirtualSystemManagementService", + "KVM_VirtualSystemManagementService", + NULL +}; +
This provider also supports ResourcePoolConfigurationService - could that be added as well?. Whew - this patch cleaned up a lot of redundant std_assoc blocks. Nicely done. =) -- Kaitlin Rupert IBM Linux Technology Center karupert@us.ibm.com
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196340286 -3600 # Node ID 3b849faf8ee17556ff39993a43ca3759f8604859 # Parent 0f6cf316d454a485c3cc965305dd353664873d1f RAFP: Adoption of changes to std_assoc struct in std_association This is the follow up patch to the API changes made in std_association. The struct std_assoc does now take lists for source, target and assoc classnames. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 0f6cf316d454 -r 3b849faf8ee1 src/Virt_ResourceAllocationFromPool.c --- a/src/Virt_ResourceAllocationFromPool.c Thu Nov 29 13:41:20 2007 +0100 +++ b/src/Virt_ResourceAllocationFromPool.c Thu Nov 29 13:44:46 2007 +0100 @@ -243,23 +243,51 @@ static CMPIInstance *make_ref(const CMPI return refinst; } +char* antecedent[] = { + "Xen_ProcessorPool", + "Xen_MemoryPool", + "Xen_NetworkPool", + "Xen_DiskPool", + "KVM_ProcessorPool", + "KVM_MemoryPool", + "KVM_NetworkPool", + "KVM_DiskPool", + NULL +}; + +char* dependent[] = { + "Xen_ResourceAllocationSettingData", + "KVM_ResourceAllocationSettingData", + NULL +}; + +char* assoc_classname[] = { + "Xen_ResourceAllocationFromPool", + "KVM_ResourceAllocationFromPool", + NULL +}; + static struct std_assoc _rasd_to_pool = { - .source_class = "CIM_ResourceAllocationSettingData", + .source_class = (char**)&dependent, .source_prop = "Dependent", - - .target_class = "CIM_ResourcePool", + + .target_class = (char**)&antecedent, .target_prop = "Antecedent", + + .assoc_class = (char**)&assoc_classname, .handler = rasd_to_pool, .make_ref = make_ref }; static struct std_assoc _pool_to_rasd = { - .source_class = "CIM_ResourcePool", + .source_class = (char**)&antecedent, .source_prop = "Antecedent", - .target_class = "CIM_ResourceAllocationSettingData", + .target_class = (char**)&dependent, .target_prop = "Dependent", + + .assoc_class = (char**)&assoc_classname, .handler = pool_to_rasd, .make_ref = make_ref
Heidi Eckhart wrote:
+ +char* dependent[] = { + "Xen_ResourceAllocationSettingData", + "KVM_ResourceAllocationSettingData", + NULL +}; +
Using -arc Xen_ProcResourceAllocationSettingData in a query doesn't work, but using -arc Xen_ResourceAllocationSettingData does work. Should Xen_ProcResourceAllocationSettingData, etc also added to the list? The instances we're returning aren't of type Xen_ResourceAllocationSettingData, so it seems like we should accept result class values that correspond to the class type we return. However, the Virt_ResourceAllocationSettingData provider trips me up more often than it should, so I might be way off base here. =) -- Kaitlin Rupert IBM Linux Technology Center karupert@us.ibm.com
Kaitlin Rupert wrote:
Heidi Eckhart wrote:
+ +char* dependent[] = { + "Xen_ResourceAllocationSettingData", + "KVM_ResourceAllocationSettingData", + NULL +}; +
Using -arc Xen_ProcResourceAllocationSettingData in a query doesn't work, but using -arc Xen_ResourceAllocationSettingData does work. Should Xen_ProcResourceAllocationSettingData, etc also added to the list? The instances we're returning aren't of type Xen_ResourceAllocationSettingData, so it seems like we should accept result class values that correspond to the class type we return. good catch :) ... fixed
-- Regards Heidi Eckhart Software Engineer Linux Technology Center - Open Hypervisor heidieck@linux.vnet.ibm.com ************************************************** IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Herbert Kircher Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196340636 -3600 # Node ID 559a1c5a58401f7437037cb54219dda6914e3c81 # Parent 3b849faf8ee17556ff39993a43ca3759f8604859 SDC: Adoption of changes to std_assoc struct in std_association This is the follow up patch to the API changes made in std_association. The struct std_assoc does now take lists for source, target and assoc classnames. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 3b849faf8ee1 -r 559a1c5a5840 src/Virt_SettingsDefineCapabilities.c --- a/src/Virt_SettingsDefineCapabilities.c Thu Nov 29 13:44:46 2007 +0100 +++ b/src/Virt_SettingsDefineCapabilities.c Thu Nov 29 13:50:36 2007 +0100 @@ -811,16 +811,17 @@ static CMPIInstance *make_ref(const CMPI struct std_assoc_info *info, struct std_assoc *assoc) { - CMPIInstance *refinst; - char *base; - - base = class_base_name(assoc->assoc_class); - if (base == NULL) + CMPIStatus s = {CMPI_RC_OK, NULL}; + CMPIInstance *refinst = NULL; + virConnectPtr conn = NULL; + + conn = connect_by_classname(_BROKER, CLASSNAME(ref), &s); + if (conn == NULL) return NULL; refinst = get_typed_instance(_BROKER, - CLASSNAME(ref), - base, + pfx_from_conn(conn), + "SettingsDefineCapabilities", NAMESPACE(ref)); if (refinst != NULL) { @@ -834,32 +835,50 @@ static CMPIInstance *make_ref(const CMPI (CMPIValue *)&instop, CMPI_ref); } - free(base); + virConnectClose(conn); return refinst; } +char* group_component[] = { + "Xen_AllocationCapabilities", + "KVM_AllocationCapabilities", + NULL +}; + +char* part_component[] = { + "Xen_ResourceAllocationSettingData", + "KVM_ResourceAllocationSettingData", + NULL +}; + +char* assoc_classname[] = { + "Xen_SettingsDefineCapabilities", + "KVM_SettingsDefineCapabilities", + NULL +}; + struct std_assoc _alloc_cap_to_rasd = { - .source_class = "CIM_AllocationCapabilities", + .source_class = (char**)&group_component, .source_prop = "GroupComponent", - .target_class = "CIM_ResourceAllocationSettingData", + .target_class = (char**)&part_component, .target_prop = "PartComponent", - .assoc_class = "CIM_SettingsDefineCapabilities", + .assoc_class = (char**)&assoc_classname, .handler = alloc_cap_to_rasd, .make_ref = make_ref }; struct std_assoc _rasd_to_alloc_cap = { - .source_class = "CIM_ResourceAllocationSettingData", + .source_class = (char**)&part_component, .source_prop = "PartComponent", - .target_class = "CIM_AllocationCapabilities", + .target_class = (char**)&group_component, .target_prop = "GroupComponent", - .assoc_class = "CIM_SettingsDefineCapabilities", + .assoc_class = (char**)&assoc_classname, .handler = rasd_to_alloc_cap, .make_ref = make_ref
Heidi Eckhart wrote:
diff -r 3b849faf8ee1 -r 559a1c5a5840 src/Virt_SettingsDefineCapabilities.c --- a/src/Virt_SettingsDefineCapabilities.c Thu Nov 29 13:44:46 2007 +0100 +++ b/src/Virt_SettingsDefineCapabilities.c Thu Nov 29 13:50:36 2007 +0100 @@ -811,16 +811,17 @@ static CMPIInstance *make_ref(const CMPI struct std_assoc_info *info, struct std_assoc *assoc) { - CMPIInstance *refinst; - char *base; - - base = class_base_name(assoc->assoc_class); - if (base == NULL) + CMPIStatus s = {CMPI_RC_OK, NULL}; + CMPIInstance *refinst = NULL; + virConnectPtr conn = NULL; + + conn = connect_by_classname(_BROKER, CLASSNAME(ref), &s); + if (conn == NULL) return NULL;
refinst = get_typed_instance(_BROKER, - CLASSNAME(ref), - base, + pfx_from_conn(conn), + "SettingsDefineCapabilities", NAMESPACE(ref));
if (refinst != NULL) { @@ -834,32 +835,50 @@ static CMPIInstance *make_ref(const CMPI (CMPIValue *)&instop, CMPI_ref); }
- free(base); + virConnectClose(conn);
return refinst; } Would it be possible to break these changes out into a separate patch as well? Good job catching these - I think there's enough for a connect_by_classname() patchset. =)
-- Kaitlin Rupert IBM Linux Technology Center karupert@us.ibm.com
Kaitlin Rupert wrote:
Would it be possible to break these changes out into a separate patch as well? Good job catching these - I think there's enough for a connect_by_classname() patchset. =) I would like to do so, but the problem is, that the code does not compile without this fix. So I decided to fix this issue where necessary to get all assoc providers compiled and added fixing the other make_ref() functions to my ToDo list. Is this ok for this time ?
-- Regards Heidi Eckhart Software Engineer Linux Technology Center - Open Hypervisor heidieck@linux.vnet.ibm.com ************************************************** IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Herbert Kircher Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196341011 -3600 # Node ID 06cf0d4357cbfc21a051f26659f5c64dc2cc0c16 # Parent 559a1c5a58401f7437037cb54219dda6914e3c81 SDS: Adoption of changes to std_assoc struct in std_association This is the follow up patch to the API changes made in std_association. The struct std_assoc does now take lists for source, target and assoc classnames. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 559a1c5a5840 -r 06cf0d4357cb src/Virt_SettingsDefineState.c --- a/src/Virt_SettingsDefineState.c Thu Nov 29 13:50:36 2007 +0100 +++ b/src/Virt_SettingsDefineState.c Thu Nov 29 13:56:51 2007 +0100 @@ -301,33 +301,73 @@ static CMPIInstance *make_ref(const CMPI return refinst; } +char* logical_device[] = { + "Xen_Processor", + "Xen_Memory", + "Xen_Network", + "Xen_Disk", + "KVM_Processor", + "KVM_Memory", + "KVM_Network", + "KVM_Disk", + NULL +}; + +char* resource_allocation_setting_data[] = { + "Xen_ResourceAllocationSettingData", + "KVM_ResourceAllocationSettingData", + NULL +}; + +char* computer_system[] = { + "Xen_ComputerSystem", + "KVM_ComputerSystem", + NULL +}; + +char* virtual_system_setting_data[] = { + "Xen_VirtualSystemSettingData", + "KVM_VirtualSystemSettingData", + NULL +}; + +char* assoc_classname[] = { + "Xen_SettingsDefineState", + "KVM_SettingsDefineState", + NULL +}; + static struct std_assoc _dev_to_rasd = { - .source_class = "CIM_LogicalDevice", + .source_class = (char**)&logical_device, .source_prop = "ManagedElement", - .target_class = "CIM_ResourceAllocationSettingData", + .target_class = (char**)&resource_allocation_setting_data, .target_prop = "SettingData", + + .assoc_class = (char**)&assoc_classname, .handler = dev_to_rasd, .make_ref = make_ref }; static struct std_assoc _rasd_to_dev = { - .source_class = "CIM_ResourceAllocationSettingData", + .source_class = (char**)&resource_allocation_setting_data, .source_prop = "SettingData", - .target_class = "CIM_LogicalDevice", + .target_class = (char**)&logical_device, .target_prop = "ManagedElement", + + .assoc_class = (char**)&assoc_classname, .handler = rasd_to_dev, .make_ref = make_ref }; static struct std_assoc _vs_to_vssd = { - .source_class = "CIM_ComputerSystem", + .source_class = (char**)&computer_system, .source_prop = "ManagedElement", - .target_class = "CIM_VirtualSystemSettingData", + .target_class = (char**)&virtual_system_setting_data, .target_prop = "SettingData", .handler = vs_to_vssd, @@ -335,10 +375,10 @@ static struct std_assoc _vs_to_vssd = { }; static struct std_assoc _vssd_to_vs = { - .source_class = "CIM_VirtualSystemSettingData", + .source_class = (char**)&virtual_system_setting_data, .source_prop = "SettingData", - .target_class = "CIM_ComputerSystem", + .target_class = (char**)&computer_system, .target_prop = "ManagedElement", .handler = vssd_to_vs,
Heidi Eckhart wrote:
+ +char* resource_allocation_setting_data[] = { + "Xen_ResourceAllocationSettingData", + "KVM_ResourceAllocationSettingData", + NULL +};
I think this has the same potiential issue as RAFP: should we also include the specific subclasses of Xen_ResourceAllocationSettingData (Xen_ProcResourceAllocationSettingData, etc?) in the list? -- Kaitlin Rupert IBM Linux Technology Center karupert@us.ibm.com
Kaitlin Rupert wrote:
Heidi Eckhart wrote:
+ +char* resource_allocation_setting_data[] = { + "Xen_ResourceAllocationSettingData", + "KVM_ResourceAllocationSettingData", + NULL +};
I think this has the same potiential issue as RAFP: should we also include the specific subclasses of Xen_ResourceAllocationSettingData (Xen_ProcResourceAllocationSettingData, etc?) in the list?
good catch ... fixed -- Regards Heidi Eckhart Software Engineer Linux Technology Center - Open Hypervisor heidieck@linux.vnet.ibm.com ************************************************** IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Herbert Kircher Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196341254 -3600 # Node ID 357d15061ef722c1e01936f2a3faeed638526938 # Parent 06cf0d4357cbfc21a051f26659f5c64dc2cc0c16 SD: Adoption of changes to std_assoc struct in std_association This is the follow up patch to the API changes made in std_association. The struct std_assoc does now take lists for source, target and assoc classnames. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 06cf0d4357cb -r 357d15061ef7 src/Virt_SystemDevice.c --- a/src/Virt_SystemDevice.c Thu Nov 29 13:56:51 2007 +0100 +++ b/src/Virt_SystemDevice.c Thu Nov 29 14:00:54 2007 +0100 @@ -244,23 +244,51 @@ static CMPIStatus dev_to_sys(const CMPIO return s; } +char* group_component[] = { + "Xen_HostSystem", + "KVM_HostSystem", + NULL +}; + +char* part_component[] = { + "Xen_Processor", + "Xen_Memory", + "Xen_Network", + "Xen_Disk", + "KVM_Processor", + "KVM_Memory", + "KVM_Network", + "KVM_Disk", + NULL +}; + +char* assoc_classname[] = { + "Xen_SystemDevice", + "KVM_SystemDevice", + NULL +}; + static struct std_assoc forward = { - .source_class = "CIM_System", + .source_class = (char**)&group_component, .source_prop = "GroupComponent", - .target_class = "CIM_LogicalDevice", + .target_class = (char**)&part_component, .target_prop = "PartComponent", + + .assoc_class = (char**)&assoc_classname, .handler = sys_to_dev, .make_ref = make_ref }; static struct std_assoc backward = { - .source_class = "CIM_LogicalDevice", + .source_class = (char**)&part_component, .source_prop = "PartComponent", - .target_class = "CIM_System", + .target_class = (char**)&group_component, .target_prop = "GroupComponent", + + .assoc_class = (char**)&assoc_classname, .handler = dev_to_sys, .make_ref = make_ref
Heidi Eckhart wrote:
+char* group_component[] = { + "Xen_HostSystem", + "KVM_HostSystem", + NULL +}; +
I believe SystemDevice also associates virtual devices to their corresponding virtual machines. So I think Xen_ComputerSystem and KVM_ComputerSystem need to be added to that list. =) -- Kaitlin Rupert IBM Linux Technology Center karupert@us.ibm.com
Kaitlin Rupert wrote:
Heidi Eckhart wrote:
+char* group_component[] = { + "Xen_HostSystem", + "KVM_HostSystem", + NULL +}; +
I believe SystemDevice also associates virtual devices to their corresponding virtual machines. So I think Xen_ComputerSystem and KVM_ComputerSystem need to be added to that list. =)
Actually, it looks like I might be somewhat incorrect here. It looks like SystemDevice associates virtual devices to their corresponding virtual machines - I don't think it currently associates any devices to the host. -- Kaitlin Rupert IBM Linux Technology Center karupert@us.ibm.com
Kaitlin Rupert wrote:
Heidi Eckhart wrote:
+char* group_component[] = { + "Xen_HostSystem", + "KVM_HostSystem", + NULL +}; +
I believe SystemDevice also associates virtual devices to their corresponding virtual machines. So I think Xen_ComputerSystem and KVM_ComputerSystem need to be added to that list. =)
Yup - absolutely. Thanks - a very good catch :). -- Regards Heidi Eckhart Software Engineer Linux Technology Center - Open Hypervisor heidieck@linux.vnet.ibm.com ************************************************** IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Herbert Kircher Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1196341434 -3600 # Node ID 9e735b67588fd2cfa522a19fb4e48fc158196586 # Parent 357d15061ef722c1e01936f2a3faeed638526938 VSSDC: Adoption of changes to std_assoc struct in std_association This is the follow up patch to the API changes made in std_association. The struct std_assoc does now take lists for source, target and assoc classnames. Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 357d15061ef7 -r 9e735b67588f src/Virt_VSSDComponent.c --- a/src/Virt_VSSDComponent.c Thu Nov 29 14:00:54 2007 +0100 +++ b/src/Virt_VSSDComponent.c Thu Nov 29 14:03:54 2007 +0100 @@ -173,23 +173,46 @@ static CMPIInstance *make_ref(const CMPI return refinst; } +char* group_component[] = { + "Xen_VirtualSystemSettingData", + "KVM_VirtualSystemSettingData", + NULL +}; + +char* part_component[] = { + "Xen_ResourceAllocationSettingData", + "KVM_ResourceAllocationSettingData", + NULL +}; + +char* assoc_classname[] = { + "Xen_VirtualSystemSettingDataComponent", + "KVM_VirtualSystemSettingDataComponent", + NULL +}; + + static struct std_assoc forward = { - .source_class = "CIM_VirtualSystemSettingData", + .source_class = (char**)&group_component, .source_prop = "GroupComponent", - .target_class = "CIM_ResourceAllocationSettingData", + .target_class = (char**)&part_component, .target_prop = "PartComponent", + + .assoc_class = (char**)&assoc_classname, .handler = vssd_to_rasd, .make_ref = make_ref }; static struct std_assoc backward = { - .source_class = "CIM_ResourceAllocationSettingData", + .source_class = (char**)&part_component, .source_prop = "PartComponent", - .target_class = "CIM_VirtualSystemSettingData", + .target_class = (char**)&group_component, .target_prop = "GroupComponent", + + .assoc_class = (char**)&assoc_classname, .handler = rasd_to_vssd, .make_ref = make_ref
Heidi Eckhart wrote:
+char* part_component[] = { + "Xen_ResourceAllocationSettingData", + "KVM_ResourceAllocationSettingData", + NULL +}; + I think this has the same potiential issue as RAFP: should we also include the specific subclasses of Xen_ResourceAllocationSettingData (Xen_ProcResourceAllocationSettingData, etc?) in the list?
-- Kaitlin Rupert IBM Linux Technology Center karupert@us.ibm.com
Kaitlin Rupert wrote:
Heidi Eckhart wrote:
+char* part_component[] = { + "Xen_ResourceAllocationSettingData", + "KVM_ResourceAllocationSettingData", + NULL +}; + I think this has the same potiential issue as RAFP: should we also include the specific subclasses of Xen_ResourceAllocationSettingData (Xen_ProcResourceAllocationSettingData, etc?) in the list?
good catch ... fixed -- Regards Heidi Eckhart Software Engineer Linux Technology Center - Open Hypervisor heidieck@linux.vnet.ibm.com ************************************************** IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Herbert Kircher Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
Heidi Eckhart wrote:
This is the follow up patch to the API changes made in std_association. The struct std_assoc does now take lists for source, target and assoc classnames.
Mhh .. forgot to tell: please review. The compiler did not complain about something and I've tested some of them, but not all as I was not able to get references for each one. thanks ... Heidi -- Regards Heidi Eckhart Software Engineer Linux Technology Center - Open Hypervisor heidieck@linux.vnet.ibm.com ************************************************** IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Herbert Kircher Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
Heidi Eckhart wrote:
Heidi Eckhart wrote:
This is the follow up patch to the API changes made in std_association. The struct std_assoc does now take lists for source, target and assoc classnames.
Mhh .. forgot to tell: please review. The compiler did not complain about something and I've tested some of them, but not all as I was not able to get references for each one. thanks ... Heidi
I was able to test most things, but I ran into a few problems too. =) I'm seeing issues from SettingsDefineCapabilities and SystemDevice. I've also tested these on a clean tree (no patches), and I see the same problems. So these issues could be something wrong with my environment or something not related to your patches. I've added these to my list of things to investigate. =) -- Kaitlin Rupert IBM Linux Technology Center karupert@us.ibm.com
participants (3)
-
Dan Smith -
Heidi Eckhart -
Kaitlin Rupert