Re: [Xen-devel] [PATCH 00 of 26] libxl: autogenerate type definitions and destructor functions

[Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>]

On Mon, 2010-08-16 at 15:33 +0100, Ian Campbell wrote:
> 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.
> 
> tools/_libxl_types.h should be identical both before applying and
> after applying+building "libxl: autogenerate _libxl_types.h" apart
> from a "DO NOT EDIT" header.
> 
> Since last time:
> * rebased
> * corrected Makefile dependencies to include libxltypes.idl
> * manually implemented libxl_file_reference_destroy since it is more
>   complex than just freeing the contained types.
> * Made libxl_file_reference_{map,unmap} into internal functions.
> * Added typedefs for various types:
>   - libxl_cpumap
>   - libxl_hwcap
> * Made libxl_xen_console_reader an opaque type and by making the definition
>   internal.
> * moved more types from libxl.h to _libxl_types.h. I think all those
>   which it makes sense to generate are now accounted for.
> * disabled destructor generation for types which have no interesting
>   fields (i.e. had empty destructor functions). I have retained the
>   empty destructors for types which belong to a set where some types
>   do have a valid need for a destructor funntion (e.g. libxl_device_*
>   or libxl_*info)
> * Audit for usages of libxl_device_* and libxl_*info which can use the
>   new destructors. I'm sure I haven't caught them all.

Many of these patches are straight-up bug fixes that should be applied
right away. Especially:
[PATCH 25 of 26] libxl: do not GC data returned to the caller by
                 libxl_device_disk_getinfo
[PATCH 08 of 26] libxl: ensure result of libxl_poolid_to_name is always
                 dynamically allocated

Some are just a good idea anyway: specific typedefs and making some
structs opaque, 20/26 - free all data from domain monitor. I think these
should be applied as-is too.

As for auto-generation stuff, I believe that since it's produced the
right header file last few go's around then it will work in future. So
can you submit that in one chunk next time without the backup/restore
features, diffs for comparison purposes?

Good stuff


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