[Xen-devel] [PATCH 0 of 8] [RFC] libxl: autogenerate type definitions and destructor functions

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel