[RFC] libxl: autogenerate type definitions and destructor functions

From Ian Campbell – 8 Request for Comment Patches at http://lists.xensource.com/archives/html/xen-devel/2010-08/msg00099.html
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.