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: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Wed, 4 Aug 2010 18:16:16 +0100
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 04 Aug 2010 10:15:50 -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
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Tue, 3 Aug 2010, 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.
> Given that (massive) caveat the complete series does make "xl create
> -n" clean of leaks and double frees, at least as far as valgrind is
> concerned.
> I'm not yet totally happy with some aspects of the auto generation, in
> particular the type definitions should be separated from the
> scaffolding in libxltypes.py (e.g. into libxl.idl or similar) and some
> of the overly C specific constructs which have crept into the data
> types (e.g. the use of "*" in type names) need careful
> consideration. (I don't think the C-isms are universally a bad thing
> -- the use cases which are envisioned, including those relating to
> language bindings, are generally expected to be on the C side of
> things). Other areas for further work are in the area of the
> {has,generate}_destructor type annotation (currently a mess, as is the
> passing around of type annotations generally) and the representation
> of pass-by-value-ness vs pass-by-reference-ness.
> Regardless of that I think I have progressed to the point where taking
> it any further would be a potential waste of time without some
> validation of the overall concept/direction.
I really like the concept of this series, and for the moment I have
applied patches 1 and 2, I'll wait for the other issues to be settled
before applying the rest.
In particular I agree with Gianni and Ian on the fact that libxl data
structures should live in a separate idl-like file.
Regarding the memory policy: I am all for explicit freeing by the

Xen-devel mailing list