Re: [Xen-cim] Memory pool question

[Jim Fehlig <jfehlig@xxxxxxxxxx>]

Gareth S Bestor wrote:
> To further followup on this, I think for the "generic assoc provider" 
> changing to a
> bool AssocMatch(LHSObjectPath, RHSObjectPath)
>
> which the developer customizes for each different association. The 
> potential target endpoint instances can be obtained via upcalls to the 
> target class(es), as we do already, but we can change the common assoc 
> provider methods to determine this target class automagically by 
> extracting the source class from the input reference objectpath, as 
> happens today, but then query the CIM class to determine the two 
> endpoint classes, rather than having to hand-code these as we do today.
Hmm.  I don't see how to do this via CMPI.  It's not clear how to query 
the cimom about class info.  Also we need the associator class name to 
determine the class name of endpoints it associates.  The reference 
objectpath input parameter contains objectpath of one of the endpoints, 
not the association class.
Perhaps the best way to continue this discussion is through some examples.

My first thought was to create a generic getTargetEndpoints() function 
that would be called by each association provider.  So a typical entry 
pint in an association provider would look something like
CMPIStatus Associators(args)
{
   CMPIEnumeration potentialEndpoints = getTargetEndPoints(args)
   For endpoint in potentialEndpoints Do
       if AssocMatch(sourceEndpoint, endpoint)
         Add endpoint to results
}

getTargetEnpoints() signature would be something like

CMPIStatus getTargetEndpoints(CMPIBroker *, CMPIContext *,
                                       CMPIResult *, char *className,
                                       CMPIObjectPath *source, char 
*assocClass,
                                       char *resultClass, char *role, 
char *resultRole);
where className is the name of associator class invoking the function.  
Other parameters are just passed through.  So some basic filtering would 
be done in getTargetInstances(), e.g. ensuring assocClass (if provided) 
is the subject association class (or superclass of subject association 
class).  Final filtering would be done in AssocMatch - which implies it 
needs a few more paramenters??
The problem with this approach is I do not know how to determine the 
endpoints of parameter className in getTargetEndpoints() - my point 
above about not seeing how to do CIM class queries from CMPI.  
Alternatively we could pass this info to the generic getTargetEnpoints() 
- perhaps embedded in a structure that we define in the generic code.
Suggestions?  Does this even closely resemble what you were thinking 
Gareth?  If not maybe some tweaking of the examples will help :-).
Thanks,
Jim


> This would give us generic top-level assoc methods that are basically 
> class agnostic, and the programmer only needs to customize 
> AssocMatch(), much like the resource abstraction layer we have in the 
> instnace providers. Obviously, using upcalls to get *all* potential 
> target instances is not the most efficient, but its probbaly the 
> simplest. A more efficient approach would be to use a 
> ExecQuery(class,query) upcall - instead of EnumInstnaces(class) and 
> then filter - to more selectively pick out target instances, which 
> would translate into converting AssocMatch into a complex ExecQuery 
> WQL query experssion.
> Thoughts...
>
> - Gareth
>
>
> Inactive hide details for Gareth S Bestor/Beaverton/IBM@IBMUSGareth S 
> Bestor/Beaverton/IBM@IBMUS
>
>                         *Gareth S Bestor/Beaverton/IBM@IBMUS*
>                         Sent by: xen-cim-bounces@xxxxxxxxxxxxxxxxxxx
>
>                         09/28/06 10:27 PM
>
>         
>
> To
>         
> Jim Fehlig <jfehlig@xxxxxxxxxx>
>
> cc
>         
> xen-cim@xxxxxxxxxxxxxxxxxxx
>
> Subject
>         
> Re: [Xen-cim] Memory pool question
>
>         
>
>
> Yup, all the association provider code *should* be mostly cookie 
> cutter, with only changing a few globals necessary to customize to 
> specific applications, namely:
> /
> /* Info about the left and right hand side classes of this association. */
> static char * _ASSOCCLASS = "Xen_RunningOS";/
> /
> static char * _LHSCLASSNAME = "Xen_ComputerSystem";
> static char * _LHSPROPERTYNAME = "Dependent";/
> /
> static char * _RHSCLASSNAME = "Xen_OperatingSystem";
> static char * _RHSPROPERTYNAME = "Antecedent";/
> /
> /* Key property of the LHS and RHS objects that must match to make the 
> association. */
> static char * _LHSKEYNAME = "Name";
> static char * _RHSKEYNAME = "CSName";/
>
> However, some of the assoc providers dont use this 'new' version with 
> the LHS and RHS keyname check. Typically, when the assoc was always 
> 1:1 it was just a matter of enumerating the target class, as opposed 
> to looking for specific matching instances, the simpler version w/o 
> LHSKEYNAME and RHSKEYNAME was employed.
> Although these template can (and have!) simplified making new assoc 
> providers, both the assoc provider templates and the base instance 
> provider templates do end up re-using a lot of common code across a 
> lot of providers. So figuring out a good way to dump some/most/all of 
> this code into shared libs could I think greatly reduce the footprint 
> of these providers. Also, although the cookie cutter approach also 
> made it easy for me to mock up a lot of providers quickly, and after a 
> handful of refinements I was pretty satisfied with the template and 
> stopped tweaking them, actually putting all the common code *in one 
> place* (rather than trying to maintain 30-odd copies of it from 
> various points in time) will make future maintenance and retro-fitting 
> bug fixes/changes a LOT easier in the long run. So definitely, there 
> is a LOT more that can be done here to really optimize and extract the 
> common code from all the providers and package it in a better way. I'd 
> LOVE to discuss ideas (alas, not tomrrow morning 'cause I cant make it :-)
> - Gareth
>
> Inactive hide details for Jim Fehlig <jfehlig@xxxxxxxxxx>Jim Fehlig 
> <jfehlig@xxxxxxxxxx>
>                                                 *Jim Fehlig
>                                                 <jfehlig@xxxxxxxxxx>*
>                                                 Sent by:
>                                                 
> xen-cim-bounces@xxxxxxxxxxxxxxxxxxx
>
>
>                                                 09/28/06 04:25 PM
>
>         
> To
>         
> "Subrahmanian, Raj" <raj.subrahmanian@xxxxxxxxxx>
> cc
>         
> xen-cim@xxxxxxxxxxxxxxxxxxx
> Subject
>         
> Re: [Xen-cim] Memory pool question
>
>         
>
>
> Subrahmanian, Raj wrote:
> > Jim,
> >  
> >> Are you working on Xen_Memory, Xen_MemoryPool and all of the
> >> related associations? I'm about done with it :-/. Pretty much
> >> a repeat of the Processor stuff I finished a while back. In
> >> fact, many of the associations have common code that needs to
> >> be abstracted out. It would have significant impact on lines
> >> of code :-).
> >>
> >> In addition I have another version of the memory stuff (and
> >> all other providers that touch Xen) for the new C bindings.
> >>    
> >
> > Have you checked in your changes into the repository?
> > When I checked the repo last, it was still in the earlier state.
> >  
>
> Just checked it in.  MemoryPool and all of its associations now exist.
>
> > Have you started working on abstracting out the common code?
> >  
>
> No.  This is probably the next task.  Perhaps we can discuss some issues
> related to this on tomorrow's call.
>
> Jim
>
>
> _______________________________________________
> Xen-cim mailing list
> Xen-cim@xxxxxxxxxxxxxxxxxxxx
> __http://lists.xensource.com/xen-cim_
> _______________________________________________
> Xen-cim mailing list
> Xen-cim@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-cim
_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim