Re: [Xen-cim] Memory pool question

[Gareth S Bestor <bestor@xxxxxxxxxx>]

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.

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


Gareth 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

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@xxxxxxxxxxxxxxxxxxx
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