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/
Home Products Support Community News


Re: [Xen-devel] [PATCH 0 of 8] [RFC] libxl: autogenerate type definition

To: Ian Campbell <ian.campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0 of 8] [RFC] libxl: autogenerate type definitions and destructor functions
From: Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
Date: Wed, 4 Aug 2010 11:25:03 +0100
Cc: Ian, Campbell <Ian.Campbell@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 04 Aug 2010 03:29:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <patchbomb.1280833215@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <patchbomb.1280833215@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2010-08-03 at 12:00 +0100, Ian Campbell wrote:
> This series is an RFC (I couldn't convince "hg email" to mark mails
> other than the first as such).
> The series introduces auto-generation of the type definitions used in
> the libxl interface followed by auto-generation of a destructor
> function for each type. In the future it may be possible to use the
> related data structures for other purposes, for example auto-generation
> of the functions to marshal between C and language binding data types.
> The utility of the destructor functions is related to the direction
> taken by libxl wrt allocations made by the library vs. those made by
> the caller i.e. attaching stuff to the libxl context vs explicit
> freeing by the caller. Given the current ad-hoc nature of the
> implementation of the current "policy" (and I use the word a loosely)
> across to libxl/xl interface today this patchset is likely to introduce
> either double-frees or leaks depending on which approach is currently
> used for a given allocation so this series is definitely intended to
> follow (or be incorporated into) a series which makes a firm decision
> about that policy and implements it.

Speaking of which, part of that work in libxl will include me sprinkling
some gcc __attribute__((visibility("hidden"))) around the place and
other general librification work. Probably it would be a good idea to
extend this code to generate member get/set functions too so that we can
actually hide these structures behind a defined ABI.

I am not proposing stable ABI just yet, but it's probably about time to
start thinking about that seriously as toolstacks and libvirt etc. may
start depending on libxl soonish.


Xen-devel mailing list