From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [Xen-devel] Re: [PATCH 2 of 4] xc: split xc non-upstream bindings into xcext module Date: Mon, 22 Nov 2010 13:05:23 +0000 Message-ID: <1290431123.31507.6481.camel@zakaz.uk.xensource.com> References: <4CE539E4.9000204@eu.citrix.com> <1290094550.31507.5391.camel@zakaz.uk.xensource.com> <19686.46942.593712.651242@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <19686.46942.593712.651242-msK/Ju9w1zmnROeE8kUsYhEHtJm+Wo+I@public.gmane.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-api-bounces-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org Errors-To: xen-api-bounces-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org To: Ian Jackson Cc: xen-devel , Vincent Hanquez , "xen-api-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org" List-Id: xen-devel@lists.xenproject.org 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.