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

["Subrahmanian, Raj" <raj.subrahmanian@xxxxxxxxxx>]

My concern is as follows : If the libxen library is linked in
dynamically into one or more independent clients, and someone decides to
do xen_fini while someone else is still using it, won't it cause
problems? Surely we can't expect random clients to be able to cooperate?

Raj
> -----Original Message-----
> From: Jim Fehlig [mailto:jfehlig@xxxxxxxxxx] 
> Sent: Wednesday, December 27, 2006 12:50 AM
> To: Subrahmanian, Raj
> Cc: Ewan Mellor; xen-cim@xxxxxxxxxxxxxxxxxxx; Gareth S Bestor
> Subject: Re: [Xen-cim] Emailing: libxen.diff
> 
> 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