xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0 of 8] [RFC] libxl: autogenerate type definitions and destructor functions
@ 2010-08-03 11:00 Ian Campbell
  2010-08-03 11:00 ` [PATCH 1 of 8] libxl: add a specific UUID type Ian Campbell
                   ` (9 more replies)
  0 siblings, 10 replies; 20+ messages in thread
From: Ian Campbell @ 2010-08-03 11:00 UTC (permalink / raw)
  To: xen-devel; +Cc: Ian Campbell

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.

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2010-08-10 14:48 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-08-03 11:00 [PATCH 0 of 8] [RFC] libxl: autogenerate type definitions and destructor functions Ian Campbell
2010-08-03 11:00 ` [PATCH 1 of 8] libxl: add a specific UUID type Ian Campbell
2010-08-03 11:00 ` [PATCH 2 of 8] libxl: add a specific MAC address type Ian Campbell
2010-08-03 11:00 ` [PATCH 3 of 8] libxl: move type definitions into _libxl_types.h Ian Campbell
2010-08-03 11:00 ` [PATCH 4 of 8] libxl: tweak formatting/whitespace of _libxl_types.h Ian Campbell
2010-08-03 11:00 ` [PATCH 5 of 8] libxl: autogenerate _libxl_types.h Ian Campbell
2010-08-03 12:13   ` Gianni Tedesco
2010-08-03 12:29     ` Ian Campbell
2010-08-03 12:36       ` Gianni Tedesco
2010-08-03 13:30       ` Ian Campbell
2010-08-03 11:00 ` [PATCH 6 of 8] libxl: add KeyedUnion type Ian Campbell
2010-08-03 11:00 ` [PATCH 7 of 8] libxl: generate destructors for each libxl defined type Ian Campbell
2010-08-03 12:07   ` Gianni Tedesco
2010-08-03 12:24     ` Ian Campbell
2010-08-03 12:34       ` Gianni Tedesco
2010-08-03 11:00 ` [PATCH 8 of 8] xl: free the libxl types contained in struct domain_config Ian Campbell
2010-08-04 10:25 ` [PATCH 0 of 8] [RFC] libxl: autogenerate type definitions and destructor functions Gianni Tedesco
2010-08-04 17:16 ` Stefano Stabellini
2010-08-10 14:41   ` Ian Jackson
2010-08-10 14:48     ` Ian Campbell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).