| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH 0 of 8] [RFC] libxl: autogenerate type definition
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
caller.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home