From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Jackson Subject: [Xen-devel] Re: [PATCH 2 of 4] xc: split xc non-upstream bindings into xcext module Date: Fri, 19 Nov 2010 17:43:58 +0000 Message-ID: <19686.46942.593712.651242@mariner.uk.xensource.com> References: <4CE539E4.9000204@eu.citrix.com> <1290094550.31507.5391.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1290094550.31507.5391.camel-o4Be2W7LfRlXesXXhkcM7miJhflN2719@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 Campbell Cc: xen-devel , Vincent Hanquez , "xen-api-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org" List-Id: xen-devel@lists.xenproject.org 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. > 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. Ian.