Re: [Xen-cim] Emailing: libxen.diff - Jim Fehlig - com.xensource.lists.xen-cim

8 messages in com.xensource.lists.xen-cimRe: [Xen-cim] Emailing: libxen.diff

From	Sent On	Attachments
Subrahmanian, Raj	22 Dec 2006 19:00	.diff
Ewan Mellor	23 Dec 2006 02:12
Subrahmanian, Raj	23 Dec 2006 23:20
Ewan Mellor	24 Dec 2006 03:50
Gareth S Bestor	24 Dec 2006 13:46
Jim Fehlig	26 Dec 2006 21:49
Subrahmanian, Raj	02 Jan 2007 08:33
Jim Fehlig	02 Jan 2007 09:06

Subject:	Re: [Xen-cim] Emailing: libxen.diff
From:	Jim Fehlig (jfeh...@novell.com)
Date:	12/26/2006 09:49:43 PM
List:	com.xensource.lists.xen-cim

Ewan Mellor wrote: [snip]

Having xen_init and xen_fini gives you the most flexibility -- if you know that you're in a threaded environment, or are loading as a dynamic module, then you can wrap them up appropriately, and if you're running in a statically compiled program, then you can just call them at the top and bottom of main().

For your particular problem, I think you just need to push the mutex up into the CIM provider rather than libxen, and everything should be fine.

We can handle this in the providers -- with some changes to the existing structure. Currently we have this:

-------------------------- | cimom | -------------------------- ----------- ----------- | prov1 | | provN | | xenutils | | xenutils | ----------- ----------- -------------------------- | libxenapi | --------------------------

all in one (cimom) process. Recall that the cimom dynamically loads the target provider when receiving a request and dynamically unloads the provider after a cimom-configured interval of inactivity.

Currently xenutils is a libtool convenience library, meaning all objects in the lib are linked into each provider. We can change xenutils to a shared lib and wrap xen_[init|fini] there. xenutils contains enough code that this should be done anyway, decreasing the providers' memory footprint.

I can take care of this when cleaning up our session handling. As Gareth mentioned in a subsequent email in this thread, we'll start making use of the provider Initialize and Cleanup routines. Now that we're crawling, it's time to start walking with some stability :-).

Jim