[Libvirt-cim] [PATCH] Enhance handling of input parameter of std_association logic

[Heidi Eckhart]

Kaitlin Rupert wrote:
> Heidi Eckhart wrote:
>>          for (i = 0; comp_class_list[i]; i++) {
>>                  comp_class = comp_class_list[i];
>>
>> -                if ((test_class == NULL) ||
>> -                    (comp_class == NULL) ||
>> -                    match_op(broker, rop, comp_class))
>> +                if (!CMClassPathIsA(broker, rop, comp_class, NULL))
>>                          return true;
>>          }
>>   
> I like the idea of this approach - I think it will help with 
> scalability in the future if we decide to add support for new VMs.  I 
> have a few comments though. =)
>
> I'm not sure about this change here.  If you return true here, then 
> you're accepting just about anything as a possible result class.  ECTP 
> for example, the following query accepts Xen_Processor as a valid 
> result class:
>
>    wbemcli ain -ac Xen_ElementConformsToProfile -arc Xen_Process 
> 'http://root:elm3b41@localhost/root/interop:Xen_RegisteredProfile.InstanceID="CIM:DSP1042-SystemVirtualization-1.0.0"' 
>
>
> I tried modifying this line so that it is  
> +                if (CMClassPathIsA(broker, rop, comp_class, NULL))
>
A very good catch :) ! Fixed this in the new version. Thanks :) !
>
> However, the problem with this is that it only allows result class to 
> be one of the items in the list supplied by the handler.  For example, 
> ETCP has:
> +char* managed_element[] = {
> +        "Xen_HostSystem",
> +        "Xen_ComputerSystem",
> +        "KVM_HostSystem",
> +        "KVM_ComputerSystem",
> +        NULL
> +};
>
> The result class in the following query would not be valid because it 
> doesn't appear in the list.
>      wbemcli ain -ac Xen_ElementConformsToProfile -arc 
> CIM_ManagedElement 
> 'http://root:elm3b41@localhost/root/interop:Xen_RegisteredProfile.InstanceID="CIM:DSP1042-SystemVirtualization-1.0.0"' 
>
>
> We can't just add CIM_ManagedElement to the list because this same 
> list is being used for the source class. The source class needs to be 
> specific.  Thoughts?  I'm not sure if I'm correct in this line of 
> thinking.  =)
The problem was, that I swapped the classes - the next patch will show 
it correct:
+                rop = CMNewObjectPath(broker, ns, comp_class, NULL);
+
+                if (CMClassPathIsA(broker, rop, test_class, NULL))
                         return true;

The CMPI Spec tells the following about CMClassPathIsA:
Function to determine whether a CIM class is of "type" or any of "type" 
subclasses.
CMPIBoolean CMClassPathIsA (const CMPIBroker* mb, const CMPIObjectPath* 
op, const char* type, CMPIStatus* rc)

So with the fixes your mentioned wbemain request works now. One thing 
that also caused a problem was, that the classes Xen/KVM_ComputerSystem 
and Xen/KVM_HostSystem haven't been registered to the interop namespace 
(sure, why should they ... ;) ). This is now also fixed with the patch 
for ECTP. But only the classes, not the provider are registered, because 
the DMTF Profile Spec tells us, that no instances of them are available 
in the interop namespace. It was my fault to choose the one 
cross-namespace association we have for implementing this 
functionality... ;).

-- 
Regards

Heidi Eckhart
Software Engineer
Linux Technology Center - Open Hypervisor

heidieck at 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