Re: [Xen-cim] Emailing: libxen.diff

[Jim Fehlig <jfehlig@xxxxxxxxxx>]

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


_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim