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(a)us.ibm.com