[PATCH 0 of 2] ECTP now takes care of Xen and KVM specific requests
Changes to association ElementConformsToProfile mof and sources to take care of Xen and KVM specific requests.
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1195041966 -3600 # Node ID 3f68d001fb46af7273a427f54f143e31f3277ecf # Parent bf34b18aba9f05fd04bd5a184ad066adc28f1d6f ECTP: Updated Reference properties in mof file to Xen and KVM specific classes Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r bf34b18aba9f -r 3f68d001fb46 Makefile.am --- a/Makefile.am Wed Nov 14 12:50:38 2007 +0100 +++ b/Makefile.am Wed Nov 14 13:06:06 2007 +0100 @@ -21,6 +21,7 @@ MOFS = \ schema/ProcessorPool.mof \ schema/DiskPool.mof \ schema/HostedResourcePool.mof \ + schema/RegisteredProfile.mof \ schema/ElementConformsToProfile.mof \ schema/ComputerSystemIndication.mof \ schema/ResourceAllocationSettingData.mof \ diff -r bf34b18aba9f -r 3f68d001fb46 schema/ElementConformsToProfile.mof --- a/schema/ElementConformsToProfile.mof Wed Nov 14 12:50:38 2007 +0100 +++ b/schema/ElementConformsToProfile.mof Wed Nov 14 13:06:06 2007 +0100 @@ -6,6 +6,10 @@ ] class Xen_ElementConformsToProfile : CIM_ElementConformsToProfile { + + [Override ("ConformantStandard")] + Xen_RegisteredProfile REF ConformantStandard; + }; [Association, @@ -14,5 +18,9 @@ class Xen_ElementConformsToProfile : CIM ] class KVM_ElementConformsToProfile : CIM_ElementConformsToProfile { + + [Override ("ConformantStandard")] + KVM_RegisteredProfile REF ConformantStandard; + };
Heidi Eckhart wrote:
] class Xen_ElementConformsToProfile : CIM_ElementConformsToProfile { + + [Override ("ConformantStandard")] + Xen_RegisteredProfile REF ConformantStandard; + };
[Association, @@ -14,5 +18,9 @@ class Xen_ElementConformsToProfile : CIM ] class KVM_ElementConformsToProfile : CIM_ElementConformsToProfile { + + [Override ("ConformantStandard")] + KVM_RegisteredProfile REF ConformantStandard; + };
What is override being used for here? Doesn't CIM_ElementConformsToProfile already specify CIM_RegisteredProfile as a conformant standard ref? -- Kaitlin Rupert IBM Linux Technology Center karupert@us.ibm.com
# HG changeset patch # User Heidi Eckhart <heidieck@linux.vnet.ibm.com> # Date 1195042730 -3600 # Node ID c5e23709746cbe95546cf99283ac1143f7684490 # Parent 3f68d001fb46af7273a427f54f143e31f3277ecf ECTP: Updated std_assoc structs to reflect changes in mof Signed-off-by: Heidi Eckhart <heidieck@linux.vnet.ibm.com> diff -r 3f68d001fb46 -r c5e23709746c src/Virt_ElementConformsToProfile.c --- a/src/Virt_ElementConformsToProfile.c Wed Nov 14 13:06:06 2007 +0100 +++ b/src/Virt_ElementConformsToProfile.c Wed Nov 14 13:18:50 2007 +0100 @@ -192,35 +192,63 @@ static CMPIInstance *make_ref(const CMPI return assoc_inst; } -struct std_assoc forward = { - .source_class = "CIM_RegisteredProfile", +struct std_assoc xen_prof_to_me = { + .source_class = "Xen_RegisteredProfile", .source_prop = "ConformantStandard", .target_class = "CIM_ManagedElement", .target_prop = "ManagedElement", - .assoc_class = NULL, + .assoc_class = "Xen_ElementConformsToProfile", .handler = prof_to_elem, .make_ref = make_ref }; -struct std_assoc backward = { +struct std_assoc kvm_prof_to_me = { + .source_class = "KVM_RegisteredProfile", + .source_prop = "ConformantStandard", + + .target_class = "CIM_ManagedElement", + .target_prop = "ManagedElement", + + .assoc_class = "KVM_ElementConformsToProfile", + + .handler = prof_to_elem, + .make_ref = make_ref +}; + +struct std_assoc xen_me_to_prof = { .source_class = "CIM_ManagedElement", .source_prop = "ManagedElement", - .target_class = "CIM_RegisteredProfile", + .target_class = "Xen_RegisteredProfile", .target_prop = "ConformantStandard", - .assoc_class = NULL, + .assoc_class = "Xen_ElementConformsToProfile", .handler = elem_to_prof, .make_ref = make_ref }; +struct std_assoc kvm_me_to_prof = { + .source_class = "CIM_ManagedElement", + .source_prop = "ManagedElement", + + .target_class = "KVM_RegisteredProfile", + .target_prop = "ConformantStandard", + + .assoc_class = "KVM_ElementConformsToProfile", + + .handler = elem_to_prof, + .make_ref = make_ref +}; + struct std_assoc *assoc_handlers[] = { - &forward, - &backward, + &xen_prof_to_me, + &kvm_prof_to_me, + &xen_me_to_prof, + &kvm_me_to_prof, NULL };
As discussed in yesterday's call, I did some testing against Pegasus and sfcb regarding the necessity of this patch. Neither Pegasus nor sfcb implement that strict input parameter checking on association calls, as it is needed. Requests that do not fulfill the client's requested result set (assocClass, role, resultRole) compared to the association definition (mof) are not filterer out. They are also handed over to the provider. An example: association ElemenentConformsToProfile Xen_RegisteredProfile is ConformantStandard for Xen_ElemenentConformsToProfile KVM_RegisteredProfile is ConformantStandard for KVM_ElemenentConformsToProfile A client request with "assocClass" Xen_ElemenentConformsToProfile and an object path of a KVM_RegisteredProfile is in regard to the mof definition a wrong request. But this request is handed over to the provider, as neither Pegasus nor sfcb does the performance-consuming check if the given object path does fulfill the mof definition. This logic is handed over to the provider code. The std_association library is already prepared for this requirement and partly implements it. The only step that needs to be done in the provider is offering the correct "configuration" to the std_association logic - which is done by this patch now (and I also saw this in some other association providers, e.g. HostedDependency). So yes, this patch duplicates information that was already given in the mof and we could definitely enhance std_association to generically retrieve the class definition from the CIMOM. The behavior seen from the client would be the same. But this minor suggested configuration step uses already existing code by the best performance. So I recommend to apply this patch. -- 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
HE> A client request with "assocClass" Xen_ElemenentConformsToProfile HE> and an object path of a KVM_RegisteredProfile is in regard to the HE> mof definition a wrong request. Okay, I understand this issue now, thanks for the clarification. What concerns me about the patch is that we have to change CIM_Foo to Xen_Foo and KVM_Foo, thus doubling the number of association descriptor blocks. Could we not solve this with another match macro or helper function that each handler calls to make sure that the prefix of the reference classname matches that of the assocClass? Such a change would add just another line per handler, instead of an entire std_assoc block for *each* new platform we wish to support. Is there any reason not to solve it this way? -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Heidi Eckhart wrote:
Changes to association ElementConformsToProfile mof and sources to take care of Xen and KVM specific requests.
Both of these patches look okay, but all this explicit separation between Xen and KVM has me a little concerned, mainly because I don't understand what makes it necessary here but unnecessary in other providers. Could you explain that a little? -- -Jay
participants (4)
-
Dan Smith -
Heidi Eckhart -
Jay Gagnon -
Kaitlin Rupert