From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Jackson <Ian.Jackson-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
Subject: Re: [Xen-devel] Re: [PATCH 2 of 4] xc: split xc
	non-upstream bindings into xcext module
Date: Tue, 23 Nov 2010 18:02:17 +0000
Message-ID: <19692.425.522250.405409@mariner.uk.xensource.com>
References: <patchbomb.1290077414@zakaz.uk.xensource.com>
	<be3de1c0aa0687ef9fa6.1290077416@zakaz.uk.xensource.com>
	<4CE539E4.9000204@eu.citrix.com>
	<1290094550.31507.5391.camel@zakaz.uk.xensource.com>
	<19686.46942.593712.651242@mariner.uk.xensource.com>
	<m2n.s.1PKW6s-0019ae@chiark.greenend.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-api-bounces-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org>
In-Reply-To: <m2n.s.1PKW6s-0019ae-QGMSyCZBOSwv4zxTlrOuLwNdhmdF6hFW@public.gmane.org>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>,
	<mailto:xen-api-request-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org?subject=unsubscribe>
List-Post: <mailto:xen-api-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org>
List-Help: <mailto:xen-api-request-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>,
	<mailto:xen-api-request-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org?subject=subscribe>
Sender: xen-api-bounces-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org
Errors-To: xen-api-bounces-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org
To: Ian Campbell <Ian.Campbell-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
Cc: xen-devel <xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org>, Vincent Hanquez <Vincent.Hanquez-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>, "xen-api-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org" <xen-api-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org>
List-Id: xen-devel@lists.xenproject.org

Ian Campbell writes ("Re: [Xen-devel] Re: [Xen-API] [PATCH 2 of 4] xc: split xc non-upstream bindings into xcext module"):
> 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.

Have fun with that.  I ducked that one when I was doing the xc_handle
type change ...

Ian.