This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH 00 of 26] libxl: autogenerate type definitions an

To: Ian Campbell <ian.campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 00 of 26] libxl: autogenerate type definitions and destructor functions
From: Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
Date: Tue, 17 Aug 2010 13:14:02 +0100
Cc: Ian, Campbell <Ian.Campbell@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Tue, 17 Aug 2010 05:19:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <patchbomb.1281969204@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <patchbomb.1281969204@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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
[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

<Prev in Thread] Current Thread [Next in Thread>