[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 0 of 8] [RFC] libxl: autogenerate type definitions and destructor functions
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |