Dan Smith wrote:
KR> Applying these patches didn't fix the dups for me (btw, thanks for KR> finding the dups!). I think the Virt_ provider still gets called KR> twice.
Yeah, with more testing, I still get dups as well. Changing back to a unified provider name doesn't change the fact that the CIMOM still calls the provider once per registered class. Yes, for Pegasus, but not for sfcb - sfcb calls the association provider only once, with the client's assocClass (e.g. CIM_SystemDevice), while Pegasus manipulates assocClass to fit the subclass' association name (Xen_SystemDevice and KVM_SystemDevice) and calls the provider for each subclass. The unified case prevents us from having a key to filter on too. Therefore I added match_hypervisor_prefix() function, which compares the given ref prefix with the client requested assocClass and resultClass
My previous statement about connect_by_classname() is invalid too, because we use the ref for connecting, which will be, for example, Xen_Foo in both cases (for the KVM instance and the Xen instance of the provider's registration).
Yes, we can not use the ref to figure out for which association the
Kaitlin Rupert wrote: prefix. provider was called. :(
So, I think the bottom line is: We still need ASSOC_MATCH() and it is the proper way to fix this problem for the associations that we currently have without it.
Right?
Right.. ASSOC_MATCH() solves this problem. There might be another solution, but I'm not sure of one at the moment.
Right. And I also know, that the ASSOC_MATCH solution was developed to deal with Pegasus' special behavior to handle association requests. As mentioned above, sfcb is calling the Virt_ providers only once. We could now start a discussion which solution is the right one, but as we will not be the ones who decide on this, I would like to implement a solutions, that also makes use of the optimized sfcb behavior, where the provider is called only once. My suggestion now is, to replace ASSOC_MATCH by match_hypervisor_prefix() and register Virt_ providers instead of Xen_/KVM_ for each subclass. The advantage can not be seen with Pegasus, as Pegasus will still call the provider for each subclass with the manipulated assocClass. But for sfcb we get rid of an unnecessary provider call. What do you think ? But you both are right - the patch set is buggy and needs to be fixed in regard to ASSOC_MATCH. Thanks for making me aware of it. Will try to send out a fix as soon as possible. -- 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