|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH 0 of 8] [RFC] libxl: autogenerate type definition
On Tue, 2010-08-03 at 12:00 +0100, 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.
Speaking of which, part of that work in libxl will include me sprinkling
some gcc __attribute__((visibility("hidden"))) around the place and
other general librification work. Probably it would be a good idea to
extend this code to generate member get/set functions too so that we can
actually hide these structures behind a defined ABI.
I am not proposing stable ABI just yet, but it's probably about time to
start thinking about that seriously as toolstacks and libvirt etc. may
start depending on libxl soonish.
Gianni
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|