WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [Xen-API] [PATCH 2 of 4] xc: split xc non-upstream b

On Fri, 2010-11-19 at 17:43 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] Re: [Xen-API] [PATCH 2 of 4] xc: split xc 
> non-upstream bindings into xcext module"):
> >       * Add functionality to libxc to allow it to dlopen a backend (e.g.
> >         pointed to by an envvar) containing the hook implementation with
> >         explicit calls to the layer as necessary.
> 
> I think this is the best approach.  You could put the hook function
> pointers in the xc handle struct.

I've currently made them global (and it works ok for the cases I've
tried) but I think adding them to the xc_handle would indeed be better.

Next I need to decide what to do with the event channel interfaces in
libxenctrl which also need this treatment but which currently use a
straight integer as the handle.

I shall probably convert the evtchn interfaces to use an xc_interface
style opaque pointer as a handle, possibly/probably even reusing the
existing xc_handle type in some way since it already contains broadly
the right set of stuff.

> > Probably the second two are pretty much equivalent modulo the name of
> > the environment variable being either LD_PRELOAD or something else.
> 
> LD_PRELOAD is a sledgehammer to crack a nut for this, I think.  Also,
> I generally think that the existence of LD_PRELOAD should not be used
> as an excuse for not providing a properly-supported interface.

Agreed.

Ian.


_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api

<Prev in Thread] Current Thread [Next in Thread>