Re: [Xen-cim] Memory pool question

[Gareth S Bestor <bestor@xxxxxxxxxx>]

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