HE> Yes, for Pegasus, but not for sfcb - sfcb calls the association HE> provider only once, with the client's assocClass HE> (e.g. CIM_SystemDevice), while Pegasus manipulates assocClass to HE> fit the subclass' association name (Xen_SystemDevice and HE> KVM_SystemDevice) and calls the provider for each subclass. Ah, okay. Hmm, that's unfortunate that they behave so differently. So, if you resolve the association with an assocClass of CIM_Foo on sfcb, the provider handler actually sees CIM_Foo as the assocClass, per my testing just now. So we need to make sure that we don't use the assocClass (or resultClass) as the target of a connect_by_classname(). Might be obvious, but I just wanted to make it explicit. HE> Therefore I added match_hypervisor_prefix() function, which HE> compares the given ref prefix with the client requested assocClass HE> and resultClass prefix. Okay, looking at that now, it makes more sense. I was confusing match_hypervisor_prefix() with match_pn_to_cn(). HE> Right. And I also know, that the ASSOC_MATCH solution was developed to HE> deal with Pegasus' special behavior to handle association requests. Well, I didn't know it was special to Pegasus at the time :) I thought we were seeing the same behavior out of sfcb as well. HE> As mentioned above, sfcb is calling the Virt_ providers only HE> once. We could now start a discussion which solution is the right HE> one, but as we will not be the ones who decide on this, Personally, Pegasus' behavior makes more logical sense to me, but the sfcb case does seem more efficient. HE> I would like to implement a solutions, that also makes use of the HE> optimized sfcb behavior, where the provider is called only once. Agreed. HE> My suggestion now is, to replace ASSOC_MATCH by HE> match_hypervisor_prefix() and register Virt_ providers instead of HE> Xen_/KVM_ for each subclass. The advantage can not be seen with HE> Pegasus, as Pegasus will still call the provider for each subclass HE> with the manipulated assocClass. But for sfcb we get rid of an HE> unnecessary provider call. What do you think ? Yes, and it also eliminates the need to add an additional registration for each prefix we support, which is a good thing. Thanks Heidi! -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com