libxl: autogenerate type definitions and destructor functions
RFC PATCH 1/1 libxl: autogenerate type definitions and destructor functions
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.
PATCH 1/1 libxl: add a specific UUID type
# HG changeset patch
# User Ian Campbell <[email protected]> # Date 1280829528 -3600
# Node ID cafba5708f95cf85f55bdca322d2ff6b6769bcba # Parent b2ed7cc08554cba162f93cb95e84c2130d76b314
libxl: add a specific UUID type.
Slightly less error prone and also more amenable to autogeneration.
tools/libxl/libxl.c +1 -1
@@ -410,7 +410,7 @@ int libxl_domain_resume(libxl_ctx *ctx,* Does not modify info so that it may be reused. */ int libxl_domain_preserve (libxl_ctx *ctx,uint32_t domid, -libxl_domain_create_info *info,const char *name_suffix,uint8_t new_uuid[16 ]) +libxl_domain_create_info *info,const char *name_suffix,libxl_uuid new_uuid) {struct xs_permissions roperm[2 ];xs_transaction_t t;
tools/libxl/libxl.h +8 -6
@@ -22,8 +22,10 @@#include <xs.h> #include <sys/wait.h> /* for pid_t */ +typedef uint8_t libxl_uuid [16 ]; + typedef struct { - uint8_t uuid[16]; + libxl_uuid uuid; uint32_t domid; uint8_t running:1; uint8_t blocked:1;
@@ -50,7 +52,7 @@ typedef struct { } libxl_poolinfo;typedef struct { -uint8_t uuid[16 ]; +libxl_uuid uuid;uint32_t domid; }libxl_vminfo ;
@@ -93,7 +95,7 @@ typedef struct {bool oos;int ssidref;char *name; -uint8_t uuid[16 ]; +libxl_uuid uuid;char **xsdata;char **platformdata;uint32_t poolid;
@@ -173,7 +175,7 @@ typedef enum { typedef struct { int domid; - uint8_t uuid[16]; /* this is use only with stubdom, and must be different from the domain uuid */ + libxl_uuid uuid; /* this is use only with stubdom, and must be different from the domain uuid */ char *dom_name; char *device_model; char *saved_state;
@@ -338,7 +340,7 @@ int libxl_domain_resume(libxl_ctx *ctx,int libxl_domain_resume (libxl_ctx *ctx,uint32_t domid);int libxl_domain_shutdown (libxl_ctx *ctx,uint32_t domid,int req);int libxl_domain_destroy (libxl_ctx *ctx,uint32_t domid,int force); -int libxl_domain_preserve (libxl_ctx *ctx,uint32_t domid,libxl_domain_create_info *info,const char *name_suffix,uint8_t new_uuid[16 ]); +int libxl_domain_preserve (libxl_ctx *ctx,uint32_t domid,libxl_domain_create_info *info,const char *name_suffix,libxl_uuid new_uuid);int libxl_file_reference_map (libxl_ctx *ctx,libxl_file_reference *f);int libxl_file_reference_unmap (libxl_ctx *ctx,libxl_file_reference *f);
@@ -360,7 +362,7 @@ int libxl_run_bootloader(libxl_ctx *ctx,libxl_device_disk *disk, uint32_t domid); -char *libxl_uuid2string (libxl_ctx *ctx,const uint8_t uuid[16 ]); +char *libxl_uuid2string (libxl_ctx *ctx,const libxl_uuid uuid);/* 0 means ERROR_ENOMEM, which we have logged */ /* events handling */
tools/libxl/libxl_dom.c +1 -1
@@ -427,7 +427,7 @@ int save_device_model(libxl_ctx *ctx, uireturn 0 ; } -char *libxl_uuid2string (libxl_ctx *ctx,const uint8_t uuid[16 ]) { +char *libxl_uuid2string (libxl_ctx *ctx,const libxl_uuid uuid) {char *s =string_of_uuid (ctx, uuid);if (!s)XL_LOG (ctx,XL_LOG_ERROR ,"cannot allocate for uuid" );return s;
tools/libxl/xl_cmdimpl.c +6 -6
@@ -265,11 +265,11 @@ static void init_build_info(libxl_domain } } -static void random_uuid (uint8_t *uuid) +static void random_uuid (libxl_uuid *uuid) {int i;for (i =0 ; i <16 ; i++) - uuid[i] =rand (); + (*uuid)[i] =rand (); } static void init_dm_info(libxl_device_model_info *dm_info,
@@ -277,7 +277,7 @@ static void init_dm_info(libxl_device_mo {memset (dm_info,'\0' ,sizeof (*dm_info)); -random_uuid (&dm_info->uuid[0 ]); +random_uuid (&dm_info->uuid); dm_info->dom_name = c_info->name; dm_info->device_model ="qemu-dm" ;
@@ -586,7 +586,7 @@ static void parse_config_data(const char c_info->name =strdup (buf); else c_info->name = "test"; -random_uuid (&c_info->uuid[0 ]); +random_uuid (&c_info->uuid);if (!xlu_cfg_get_long (config,"oos" , &l)) c_info->oos = l;
@@ -1181,7 +1181,7 @@ static int preserve_domain(libxl_ctx *ctstruct tm tm;char stime[24 ]; -uint8_t new_uuid[16 ]; +libxl_uuid new_uuid;int rc;
@@ -1202,7 +1202,7 @@ static int preserve_domain(libxl_ctx *ctreturn 0 ; } -random_uuid (&new_uuid[0 ]); +random_uuid (&new_uuid);LOG ("Preserving domain %d %s with suffix%s" , domid, d_config->c_info.name, stime); rc =libxl_domain_preserve (ctx, domid, &d_config->c_info, stime, new_uuid);
PATCH 1/1 libxl: add a specific MAC address type
In reply to Ian Campbell# HG changeset patch
# User Ian Campbell <[email protected]> # Date 1280829528 -3600
# Node ID 81cc53cbda33b5cd4c498c41b3eafd73f16b15e1 # Parent cafba5708f95cf85f55bdca322d2ff6b6769bcba
libxl: add a specific MAC address type.
Slightly less error prone and also more amenable to autogeneration.
tools/libxl/libxl.h +8 -6
@@ -23,6 +23,8 @@#include <sys/wait.h> /* for pid_t */ typedef uint8_t libxl_uuid [16 ]; + +typedef uint8_t libxl_mac [6 ]; typedef struct { libxl_uuid uuid;
@@ -270,7 +272,7 @@ typedef struct {int devid;int mtu;char *model; -uint8_t mac[6 ]; +libxl_mac mac;struct in_addr ip;char *bridge;char *ifname;
@@ -280,8 +282,8 @@ typedef struct { typedef struct { int devid; - uint8_t front_mac[6]; - uint8_t back_mac[6]; + libxl_mac front_mac; + libxl_mac back_mac; uint32_t backend_domid; uint32_t domid; uint32_t trusted:1;
@@ -498,7 +500,7 @@ typedef struct {int devid;int state;char *script; -uint8_t mac[6 ]; +libxl_mac mac;int evtch;int rref_tx;int rref_rx;
@@ -654,9 +656,9 @@ typedef struct {uint32_t frontend_id;int devid;int state; -uint8_t mac[6 ]; +libxl_mac mac;int trusted; -uint8_t back_mac[6 ]; +libxl_mac back_mac;int filter_mac; } libxl_net2info;
PATCH 1/1 libxl: move type definitions into _libxl_types.h
In reply to Ian Campbell# HG changeset patch
# User Ian Campbell <[email protected]> # Date 1280829586 -3600
# Node ID e2888d315d13173ddbd8076b971d71b7deb9ef53 # Parent 81cc53cbda33b5cd4c498c41b3eafd73f16b15e1
libxl: move type definitions into _libxl_types.h
The intention is to autogenerate this file in a future patch. This pure code motion patch allows for easier before and after comparison of that patch.
tools/libxl/Makefile +4 -1
@@ -103,12 +103,15 @@ install: all ln -sf libxlutil.so.$(XLUMAJOR).$(XLUMINOR) $(DESTDIR)$(LIBDIR)/libxlutil.so.$(XLUMAJOR) ln -sf libxlutil.so.$(XLUMAJOR) $(DESTDIR)$(LIBDIR)/libxlutil.so $(INSTALL_DATA) libxlutil.a $(DESTDIR)$(LIBDIR) - $(INSTALL_DATA) libxl.h $(DESTDIR)$(INCLUDEDIR) + $(INSTALL_DATA) libxl.h _libxl_types.h $(DESTDIR)$(INCLUDEDIR) $(INSTALL_DATA) bash-completion $(DESTDIR)$(BASH_COMPLETION_DIR)/xl.sh .PHONY: clean clean: + # XXX Preserve during transition to autogeneration + cp _libxl_types.h SAVED__libxl_types.h $(RM) -f _*.h *.o *.so* *.a $(CLIENTS) $(DEPS) + mv SAVED__libxl_types.h _libxl_types.h # $(RM) -f $(AUTOSRCS) $(AUTOINCS) distclean: clean
tools/libxl/_libxl_types.h new file +243 -0
243 lines not on this page · raw message
tools/libxl/libxl.h +21 -258
300 lines not on this page · raw message
PATCH 1/1 libxl: tweak formatting/whitespace of _libxl_types.h
In reply to Ian Campbell# HG changeset patch
# User Ian Campbell <[email protected]> # Date 1280829586 -3600
# Node ID cce2e854fa97f300e1efe486a02950c7b93ac339 # Parent e2888d315d13173ddbd8076b971d71b7deb9ef53
libxl: tweak formatting/whitespace of _libxl_types.h to better suit autogeneration
This makes it easier to do a before/after comparison when the file becomes autogenerated.
tools/libxl/_libxl_types.h +158 -66
@@ -9,7 +9,6 @@ typedef struct { uint8_t paused:1; uint8_t shutdown:1; uint8_t dying:1; -/* * Valid SHUTDOWN_* value from xen/sched.h iff (shutdown||dying). *
@@ -17,7 +16,6 @@ typedef struct {* SHUTDOWN_* constant. */ unsigned int shutdown_reason; -uint64_t max_memkb;uint64_t cpu_time;uint32_t vcpu_max_id;
@@ -36,16 +34,16 @@ typedef struct {typedef struct {int xen_version_major;int xen_version_minor; -char *xen_version_extra; -char *compiler; -char *compile_by; -char *compile_domain; -char *compile_date; -char *capabilities; -char *changeset; +char * xen_version_extra; +char * compiler; +char * compile_by; +char * compile_domain; +char * compile_date; +char * capabilities; +char * changeset;unsigned long virt_start;unsigned long pagesize; -char *commandline; +char * commandline; }libxl_version_info ; typedef struct {
@@ -53,12 +51,12 @@ typedef struct {bool hap;bool oos;int ssidref; -char *name; +char * name;libxl_uuid uuid; -char **xsdata; -char **platformdata; +char ** xsdata; +char ** platformdata;uint32_t poolid; -char *poolname; +char * poolname; } libxl_domain_create_info; typedef struct {
@@ -66,9 +64,9 @@ typedef struct {* Path is always set if the file refernece is valid. However if * mapped is true then the actual file may already be unlinked. */ -char *path; +char * path;int mapped; -void *data; +void * data;size_t size; } libxl_file_reference;
@@ -97,18 +95,18 @@ typedef struct {bool acpi;bool nx;bool viridian; -char *timeoffset; +char * timeoffset;bool hpet;bool vpt_align;int timer_mode; } hvm;struct { -uint32_t slack_memkb; -const char *bootloader; -const char *bootloader_args; -char *cmdline; +uint32_t slack_memkb; +const char * bootloader; +const char * bootloader_args; +char * cmdline;libxl_file_reference ramdisk; -const char *features; +const char * features; } pv; } u; } libxl_domain_build_info;
@@ -120,51 +118,145 @@ typedef struct {unsigned long console_mfn; } libxl_domain_build_state; +/* +* Device Model information. +* +* Network is missing +*/ typedef struct {int domid; -libxl_uuid uuid;/* this is use only with stubdom, and must be different from the domain uuid */ -char *dom_name; -char *device_model; -char *saved_state; +/* +* this is use only with stubdom, and must be different from the domain uuid +*/ +libxl_uuid uuid; +char * dom_name; +char * device_model; +char * saved_state;libxl_qemu_machine_type type; -int videoram;/* size of the videoram in MB */ -bool stdvga;/* stdvga enabled or disabled */ -bool vnc;/* vnc enabled or disabled */ -char *vnclisten;/* address:port that should be listened on for the VNC server if vnc is set */ -char *vncpasswd;/* the VNC password */ -int vncdisplay;/* set VNC display number */ -bool vncunused;/* try to find an unused port for the VNC server */ -char *keymap;/* set keyboard layout, default is en-us keyboard */ -bool sdl;/* sdl enabled or disabled */ -bool opengl;/* opengl enabled or disabled (if enabled requires sdl enabled) */ -bool nographic;/* no graphics, use serial port */ -char *serial;/* serial port re-direct to pty deivce */ -char *boot;/* boot order, for example dca */ -bool usb;/* usb support enabled or disabled */ -char *usbdevice;/* enable usb mouse: tablet for absolute mouse, mouse for PS/2 protocol relative mouse */ -char *soundhw;/* enable sound hardware */ -bool apic;/* apic enabled or disabled */ -int vcpus;/* max number of vcpus */ -int vcpu_avail;/* vcpus actually available */ -int xen_platform_pci;/* enable/disable the xen platform pci device */ -char **extra;/* extra parameters pass directly to qemu, NULL terminated */ -/* Network is missing */ +/* +* size of the videoram in MB +*/ +int videoram; +/* +* stdvga enabled or disabled +*/ +bool stdvga; +/* +* vnc enabled or disabled +*/ +bool vnc; +/* +* address:port that should be listened on for the VNC server if vnc is set +*/ +char * vnclisten; +/* +* the VNC password +*/ +char * vncpasswd; +/* +* set VNC display number +*/ +int vncdisplay; +/* +* try to find an unused port for the VNC server +*/ +bool vncunused; +/* +* set keyboard layout, default is en-us keyboard +*/ +char * keymap; +/* +* sdl enabled or disabled +*/ +bool sdl; +/* +* opengl enabled or disabled (if enabled requires sdl enabled) +*/ +bool opengl; +/* +* no graphics, use serial port +*/ +bool nographic; +/* +* serial port re-direct to pty deivce +*/ +char * serial; +/* +* boot order, for example dca +*/ +char * boot; +/* +* usb support enabled or disabled +*/ +bool usb; +/* +* enable usb mouse: tablet for absolute mouse, mouse for PS/2 protocol relative mouse +*/ +char * usbdevice; +/* +* enable sound hardware +*/ +char * soundhw; +/* +* apic enabled or disabled +*/ +bool apic; +/* +* max number of vcpus +*/ +int vcpus; +/* +* vcpus actually available +*/ +int vcpu_avail; +/* +* enable/disable the xen platform pci device +*/ +int xen_platform_pci; +/* +* extra parameters pass directly to qemu, NULL terminated +*/ +char ** extra; }libxl_device_model_info ;typedef struct {uint32_t backend_domid;uint32_t domid;int devid; -bool vnc;/* vnc enabled or disabled */ -char *vnclisten;/* address:port that should be listened on for the VNC server if vnc is set */ -char *vncpasswd;/* the VNC password */ -int vncdisplay;/* set VNC display number */ -bool vncunused;/* try to find an unused port for the VNC server */ -char *keymap;/* set keyboard layout, default is en-us keyboard */ -bool sdl;/* sdl enabled or disabled */ -bool opengl;/* opengl enabled or disabled (if enabled requires sdl enabled) */ -char *display; -char *xauthority; +/* +* vnc enabled or disabled +*/ +bool vnc; +/* +* address:port that should be listened on for the VNC server if vnc is set +*/ +char * vnclisten; +/* +* the VNC password +*/ +char * vncpasswd; +/* +* set VNC display number +*/ +int vncdisplay; +/* +* try to find an unused port for the VNC server +*/ +bool vncunused; +/* +* set keyboard layout, default is en-us keyboard +*/ +char * keymap; +/* +* sdl enabled or disabled +*/ +bool sdl; +/* +* opengl enabled or disabled (if enabled requires sdl enabled) +*/ +bool opengl; +char * display; +char * xauthority; }libxl_device_vfb ; typedef struct {
@@ -178,15 +270,15 @@ typedef struct {uint32_t domid;int devid;libxl_console_constype constype; -libxl_domain_build_state *build_state; +libxl_domain_build_state * build_state; } libxl_device_console; typedef struct { uint32_t backend_domid; uint32_t domid; - char *physpath; + char * physpath; libxl_disk_phystype phystype; - char *virtpath; + char * virtpath; int unpluggable; int readwrite; int is_cdrom;
@@ -197,12 +289,12 @@ typedef struct {uint32_t domid;int devid;int mtu; -char *model; +char * model;libxl_mac mac;struct in_addr ip; -char *bridge; -char *ifname; -char *script; +char * bridge; +char * ifname; +char * script;libxl_nic_type nictype; } libxl_device_nic;
@@ -218,7 +310,7 @@ typedef struct { uint32_t front_filter_mac:1;uint32_t pdev;uint32_t max_bypasses; -char *bridge; +char * bridge; } libxl_device_net2; typedef struct {
PATCH 1/1 libxl: autogenerate _libxl_types.h
In reply to Ian Campbell# HG changeset patch
# User Ian Campbell <[email protected]> # Date 1280829586 -3600
# Node ID c87dd259a8ed069d8786aadf9e1f6e555aa6778e # Parent cce2e854fa97f300e1efe486a02950c7b93ac339
libxl: autogenerate _libxl_types.h
The libxl interface types are represented by a simple python data structure (which could be parsed from a bespoke language in the future).
This will allow the autogeneration of functions to free the component members of the libxl types. In the future it may also enable auto generation of type marshalling code for language bindings.
tools/libxl/Makefile +6 -3
@@ -51,6 +51,12 @@ _libxl_paths.h: genpath mv _$@ $@ libxl_paths.c: _libxl_paths.h + +libxl.h: _libxl_types.h + +_libxl_types.h: gentypes.py libxltypes.py + python gentypes.py __libxl_types.h + mv __libxl_types.h _libxl_types.h libxenlight.so: libxenlight.so.$(MAJOR) ln -sf $< $@
@@ -108,10 +114,7 @@ install: all .PHONY: clean clean: - # XXX Preserve during transition to autogeneration - cp _libxl_types.h SAVED__libxl_types.h $(RM) -f _*.h *.o *.so* *.a $(CLIENTS) $(DEPS) - mv SAVED__libxl_types.h _libxl_types.h # $(RM) -f $(AUTOSRCS) $(AUTOINCS) distclean: clean
tools/libxl/_libxl_types.h deleted +0 -335
335 lines not on this page · raw message
tools/libxl/gentypes.py new file +86 -0
86 lines not on this page · raw message
tools/libxl/libxltypes.py new file +377 -0
377 lines not on this page · raw message
Re: [PATCH 5 of 8] libxl: autogenerate _libxl_types.h
Quoted 8 lines · Ian Campbell
tools/libxl/libxltypes.py new file +8
-0+Types = [ + libxl_dominfo, + libxl_poolinfo, + libxl_vminfo, + libxl_version_info, + libxl_domain_create_info, + libxl_file_reference, + libxl_domain_build_info,
tools/libxl/libxltypes.py line 377
Quoted 10 lines
tools/libxl/libxltypes.py new file +10
-0+ libxl_domain_build_state, + libxl_device_model_info, + libxl_device_vfb, + libxl_device_vkb, + libxl_device_console, + libxl_device_disk, + libxl_device_nic, + libxl_device_net2, + libxl_device_pci, +]
I like the idea of the patch, I think the libxl bits should be in a separate python module though or perhaps the gentypes.py.
Also I think an integer ptr attribute on the base class would be a good idea if only to get rid of nasty whitespace issue :) -- I haven't groked the code too closely but it may also be able to fold such a thing in to has_destructor attribute? anyway...
Re: [PATCH 5 of 8] libxl: autogenerate _libxl_types.h
Quoted 20 lines · On Tue, 2010-08-03 at 13:13 +0100, Gianni Tedesco (3P) wrote:
Quoted 8 lines · Ian Campbell
tools/libxl/libxltypes.py new file +8
-0+Types = [ + libxl_dominfo, + libxl_poolinfo, + libxl_vminfo, + libxl_version_info, + libxl_domain_create_info, + libxl_file_reference, + libxl_domain_build_info,tools/libxl/libxltypes.py line 377
Quoted 10 lines
tools/libxl/libxltypes.py new file +10
-0+ libxl_domain_build_state, + libxl_device_model_info, + libxl_device_vfb, + libxl_device_vkb, + libxl_device_console, + libxl_device_disk, + libxl_device_nic, + libxl_device_net2, + libxl_device_pci, +]
Quoted 2 lines
I like the idea of the patch, I think the libxl bits should be in a separate python module though or perhaps the
gentypes.py.
I agree, and said as much in my intro mail ;-)
Quoted 4 lines
Also I think an integer ptr attribute on the base class would be a good idea if only to get rid of nasty whitespace issue :) -- I haven't groked the code too closely but it may also be able to fold such a thing in to
has_destructorattribute? anyway...
Ideally the autogenerator wouldn't concern itself with indentation/whitespace/etc at all and would simply pipe its output through a suitably formed invocation of lindent. I just hand coded it for now to match something usable if not ideal (and to be comparable to the before state).
Ian.
Re: [PATCH 5 of 8] libxl: autogenerate _libxl_types.h
Quoted 21 lines · Ian Campbell
Quoted 20 lines · On Tue, 2010-08-03 at 13:13 +0100, Gianni Tedesco (3P) wrote:
Quoted 18 lines · Ian Campbell
tools/libxl/libxltypes.py new file +18
-0+Types = [ + libxl_dominfo, + libxl_poolinfo, + libxl_vminfo, + libxl_version_info, + libxl_domain_create_info, + libxl_file_reference, + libxl_domain_build_info, + libxl_domain_build_state, + libxl_device_model_info, + libxl_device_vfb, + libxl_device_vkb, + libxl_device_console, + libxl_device_disk, + libxl_device_nic, + libxl_device_net2, + libxl_device_pci, +]
Quoted 4 lines
Quoted 2 lines
I like the idea of the patch, I think the libxl bits should be in a separate python module though or perhaps the
gentypes.py.I agree, and said as much in my intro mail ;-)
Ah I did read it but must've slipped my memory during tinkering with the patches :)
Quoted 10 lines
Quoted 4 lines
Also I think an integer ptr attribute on the base class would be a good idea if only to get rid of nasty whitespace issue :) -- I haven't groked the code too closely but it may also be able to fold such a thing in to
has_destructorattribute? anyway...Ideally the autogenerator wouldn't concern itself with indentation/whitespace/etc at all and would simply pipe its output through a suitably formed invocation of lindent. I just hand coded it for now to match something usable if not ideal (and to be comparable to the before state).
Fair enough.
Gianni
Re: [PATCH 5 of 8] libxl: autogenerate _libxl_types.h
In reply to Ian CampbellQuoted 5 lines · Ian Campbell
Quoted 3 lines
I like the idea of the patch, I think the libxl bits should be in a separate python module though or perhaps the
gentypes.py.I agree, and said as much in my intro mail ;-)
FWIW this is roughly what the patch to do this would look like (appends to the series, should really be folded back)
Ian.
libxl: separate type definitions into a separate file.
Keeps the type definitions separate from the scaffolding.
tools/libxl/Makefile +2 -2
@@ -55,8 +55,8 @@ libxl_paths.c: _libxl_paths.h libxl.h: _libxl_types.h -_libxl_types.h _libxl_types.c: gentypes.py libxltypes.py - python gentypes.py __libxl_types.h __libxl_types.c +_libxl_types.h _libxl_types.c: libxltypes.idl gentypes.py libxltypes.py + python gentypes.py libxltypes.idl __libxl_types.h __libxl_types.c mv __libxl_types.h _libxl_types.h mv __libxl_types.c _libxl_types.c
tools/libxl/gentypes.py +11 -7
@@ -92,11 +92,14 @@ def libxl_C_type_destroy(ty, v, indent = return s.replace("\n", "\n%s" % indent) if __name__ == '__main__': - if len(sys.argv) < 3: - print >>sys.stderr, "Usage: gentypes.py <header> <implementation>" + if len(sys.argv) < 4: + print >>sys.stderr, "Usage: gentypes.py <idl> <header> <implementation>" sys.exit(1) - header = sys.argv[1] + idl = sys.argv[1] + (_,types) = libxltypes.parse(idl) + + header = sys.argv[2] print "outputting libxl type definitions to %s" % header f = open(header, "w")
@@ -104,7 +107,8 @@ if __name__ == '__main__': f.write("""#ifndef __LIBXL_TYPES_H #define __LIBXL_TYPES_H -/* DO NOT EDIT. +/* + * DO NOT EDIT. * * This file is autogenerated by * "%s"
@@ -112,7 +116,7 @@ if __name__ == '__main__': """ % " ".join(sys.argv)) - for ty in libxltypes.Types: + for ty in types: f.write(libxl_C_type_define(ty) + ";\n") if ty.has_destructor: f.write("void %s(%s *p);\n" % (ty.destructor, ty.typename))
@@ -121,7 +125,7 @@ if __name__ == '__main__': f.write("""#endif /* __LIBXL_TYPES_H */\n""") f.close() - impl = sys.argv[2] + impl = sys.argv[3] print "outputting libxl type implementations to %s" % impl f = open(impl, "w")
@@ -146,7 +150,7 @@ static void __string_string_free(char ** """ % " ".join(sys.argv)) - for ty in [ty for ty in libxltypes.Types if ty.generated_destructor]: + for ty in [ty for ty in types if ty.generated_destructor]: f.write("void %s(%s *p)\n" % (ty.destructor, ty.typename)) f.write("{\n") f.write(libxl_C_type_destroy(ty, "p->"))
tools/libxl/libxltypes.idl new file +250 -0
250 lines not on this page · raw message
tools/libxl/libxltypes.py +23 -266
296 lines not on this page · raw message
PATCH 1/1 libxl: add KeyedUnion type
In reply to Ian Campbell# HG changeset patch
# User Ian Campbell <[email protected]> # Date 1280829586 -3600
# Node ID 5d51a404379e3e91c08c07c8292abefa1440a655 # Parent c87dd259a8ed069d8786aadf9e1f6e555aa6778e
libxl: add KeyedUnion type
Use this to express the construct where a union is differentiated on a variable in the containing struct.
tools/libxl/libxltypes.py +35 -21
@@ -35,12 +35,13 @@ class BitField(Type): class Field(Type): """An element of an Aggregate type""" - def __init__(self, type, name, const = False, comment = None): + def __init__(self, type, name, const = False, comment = None, keyvar_expr = None): Type.__init__(self,type.typename) self.type = type self.name = name self.const = const self.comment = comment + self.keyvar_expr = keyvar_expr class Aggregate(Type): """A type containing a collection of other types"""
@@ -79,6 +80,19 @@ class KeyValueList(Type): Type.__init__(self, "char **", namespace = None) +class KeyedUnion(Aggregate): + """A union which is keyed of another variable""" + def __init__(self, name, keyvar_name, fields, comment = None): + self.keyvar = keyvar_name + Aggregate.__init__(self, "union", name, [], comment) + for f in fields: + # (name, keyvar_expr, type) + + # keyvar_expr must contain exactly one %s which will be replaced with the keyvar_name + + n, kve, ty = f + self.fields.append(Field(ty, n, False, None, kve)) + class Reference(Type): """A reference to another type""" def __init__(self, ty):
@@ -199,26 +213,26 @@ libxl_domain_build_info = Struct("domain ("disable_migrate", bool), ("kernel", libxl_file_reference), ("hvm", integer), - ("u", Union(None, - [("hvm", Struct(None, - [("pae", bool), - ("apic", bool), - ("acpi", bool), - ("nx", bool), - ("viridian", bool), - ("timeoffset", string), - ("hpet", bool), - ("vpt_align", bool), - ("timer_mode", integer), - ])), - ("pv", Struct(None, - [("slack_memkb", uint32), - ("bootloader", string, True), - ("bootloader_args", string, True), - ("cmdline", string), - ("ramdisk", libxl_file_reference), - ("features", string, True), - ])), + ("u", KeyedUnion(None, "hvm", + [("hvm", "%s", Struct(None, + [("pae", bool), + ("apic", bool), + ("acpi", bool), + ("nx", bool), + ("viridian", bool), + ("timeoffset", string), + ("hpet", bool), + ("vpt_align", bool), + ("timer_mode", integer), + ])), + ("pv", "!%s", Struct(None, + [("slack_memkb", uint32), + ("bootloader", string, True), + ("bootloader_args", string, True), + ("cmdline", string), + ("ramdisk", libxl_file_reference), + ("features", string, True), + ])), ])), ], comment =
PATCH 1/1 libxl: generate destructors for each libxl defined type
In reply to Ian Campbell# HG changeset patch
# User Ian Campbell <[email protected]> # Date 1280829586 -3600
# Node ID 6baa8ce2ec5ed5d140a67b87d2514e88464df34e # Parent 5d51a404379e3e91c08c07c8292abefa1440a655
libxl: generate destructors for each libxl defined type
I chose the name "_destroy" rather than "_free" because the destructor functions will free only the members of a type recursively but will not free the actual type structure itself. The allocation of the type is typically done by the caller and may not be a single allocation, e.g. lists/arrays of types or embedded in other strucutures etc.
.hgignore +1 -0
@@ -182,6 +182,7 @@ ^tools/libxen/test/test_bindings$ ^tools/libxen/test/test_event_handling$ ^tools/libxl/_.*\.h$ +^tools/libxl/_.*\.c$ ^tools/libxl/libxlu_cfg_y\.output$ ^tools/libxl/xl$ ^tools/libaio/src/.*\.ol$
tools/libxl/Makefile +5 -2
@@ -19,6 +19,7 @@ LIBS = $(LDFLAGS_libxenctrl) $(LDFLAGS_l LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o LIBXL_OBJS = flexarray.o libxl.o libxl_pci.o libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o libxl_internal.o xenguest.o libxl_utils.o $(LIBXL_OBJS-y) +LIBXL_OBJS += _libxl_types.c AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
@@ -54,9 +55,10 @@ libxl_paths.c: _libxl_paths.h libxl.h: _libxl_types.h -_libxl_types.h: gentypes.py libxltypes.py - python gentypes.py __libxl_types.h +_libxl_types.h _libxl_types.c: gentypes.py libxltypes.py + python gentypes.py __libxl_types.h __libxl_types.c mv __libxl_types.h _libxl_types.h + mv __libxl_types.c _libxl_types.c libxenlight.so: libxenlight.so.$(MAJOR) ln -sf $< $@
@@ -115,6 +117,7 @@ install: all .PHONY: clean clean: $(RM) -f _*.h *.o *.so* *.a $(CLIENTS) $(DEPS) + $(RM) -f _*.c # $(RM) -f $(AUTOSRCS) $(AUTOINCS) distclean: clean
tools/libxl/gentypes.py +75 -5
96 lines not on this page · raw message
tools/libxl/libxltypes.py +48 -15
137 lines not on this page · raw message
Re: [PATCH 7 of 8] libxl: generate destructors for each libxl defined type
Quoted 3 lines · Ian Campbell
LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o
LIBXL_OBJS= flexarray.o libxl.o libxl_pci.o libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o libxl_internal.o xenguest.o libxl_utils.o $(LIBXL_OBJS-y)
+LIBXL_OBJS +=_libxl_types.c
uhm... _libxl_types.o ??
Review libxl_paths.c: _libxl_paths.h · line 61
Quoted 12 lines
AUTOINCS=
libxlu_cfg_y.hlibxlu_cfg_l.h
AUTOSRCS=libxlu_cfg_y.clibxlu_cfg_l.c(quoted diff) +3
-2@@ -54,9 +55,10 @@ libxl_paths.c: _libxl_paths.h libxl.h: _libxl_types.h -_libxl_types.h: gentypes.py libxltypes.py - python gentypes.py __libxl_types.h +_libxl_types.h _libxl_types.c: gentypes.py libxltypes.py + python gentypes.py __libxl_types.h __libxl_types.c mv __libxl_types.h _libxl_types.h + mv __libxl_types.c _libxl_types.c
Something is still wrong in the dep tree that breaks a clean build. I think part of the problem is that the build system cannot find what depends on _libxl_types.h until the compile-time-generate dep files are created. On the other hand, it can't create the dep files if the _libxl_types.h is not there.
Solution is to manually tweak the dep tree, meh:
tools/libxl/Makefile +6 -4
@@ -19,7 +19,7 @@ LIBS = $(LDFLAGS_libxenctrl) $(LDFLAGS_l LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o LIBXL_OBJS = flexarray.o libxl.o libxl_pci.o libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o libxl_internal.o xenguest.o libxl_utils.o $(LIBXL_OBJS-y) -LIBXL_OBJS += _libxl_types.c +LIBXL_OBJS += _libxl_types.o AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
@@ -84,18 +84,20 @@ libxlutil.so.$(XLUMAJOR).$(XLUMINOR): $( libxlutil.a: $(LIBXLU_OBJS) $(AR) rcs libxlutil.a $^ -xl.o: xl.c +xl.o: xl.c _libxl_types.h $(CC) $(CFLAGS) -c xl.c -xl_cmdimpl.o: xl_cmdimpl.c +xl_cmdimpl.o: xl_cmdimpl.c _libxl_types.h $(CC) $(CFLAGS) -c xl_cmdimpl.c -xl_cmdtable.o: xl_cmdtable.c +xl_cmdtable.o: xl_cmdtable.c _libxl_types.h $(CC) $(CFLAGS) -c xl_cmdtable.c $(CLIENTS): xl.o xl_cmdimpl.o xl_cmdtable.o libxlutil.so libxenlight.so $(CC) $(LDFLAGS) -o $@ $^ $(LIBS) +%.so: _libxl_types.h + .PHONY: install install: all $(INSTALL_DIR) $(DESTDIR)$(SBINDIR)
Re: [PATCH 7 of 8] libxl: generate destructors for each libxl defined type
Thanks for looking over this.
Quoted 6 lines · On Tue, 2010-08-03 at 13:07 +0100, Gianni Tedesco (3P) wrote:
Quoted 3 lines · Ian Campbell
LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o
LIBXL_OBJS= flexarray.o libxl.o libxl_pci.o libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o libxl_internal.o xenguest.o libxl_utils.o $(LIBXL_OBJS-y)
+LIBXL_OBJS +=_libxl_types.cuhm... _libxl_types.o ??
Oops, yes indeed.
Quoted 19 lines
Review libxl_paths.c: _libxl_paths.h · line 61
Quoted 12 lines
AUTOINCS=
libxlu_cfg_y.hlibxlu_cfg_l.h
AUTOSRCS=libxlu_cfg_y.clibxlu_cfg_l.c(quoted diff) +3
-2@@ -54,9 +55,10 @@ libxl_paths.c: _libxl_paths.h libxl.h: _libxl_types.h -_libxl_types.h: gentypes.py libxltypes.py - python gentypes.py __libxl_types.h +_libxl_types.h _libxl_types.c: gentypes.py libxltypes.py + python gentypes.py __libxl_types.h __libxl_types.c mv __libxl_types.h _libxl_types.h + mv __libxl_types.c _libxl_types.cSomething is still wrong in the dep tree that breaks a clean build. I think part of the problem is that the build system cannot find what depends on
_libxl_types.huntil the compile-time-generate dep files are created. On the other hand, it can't create the dep files if the_libxl_types.his not there.
Quoted 1 line
Solution is to manually tweak the dep tree, meh:
I thought that the next patch in the series (which adds _libxl_types.c) also worked around the same problem so I didn't worry too much but I seem to have been mistaken.
I wonder if this can be wildcarded at all, something like
%.o: _libl_types.h
(except not that because it doesn't actually work, AFAICT)
Ian.
Quoted 39 lines
diff -r
87613ac31ddctools/libxl/Makefiletools/libxl/Makefile +6
-4@@ -19,7 +19,7 @@ LIBS = $(LDFLAGS_libxenctrl) $(LDFLAGS_l LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o LIBXL_OBJS = flexarray.o libxl.o libxl_pci.o libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o libxl_internal.o xenguest.o libxl_utils.o $(LIBXL_OBJS-y) -LIBXL_OBJS += _libxl_types.c +LIBXL_OBJS += _libxl_types.o AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c@@ -84,18 +84,20 @@ libxlutil.so.$(XLUMAJOR).$(XLUMINOR): $( libxlutil.a: $(LIBXLU_OBJS) $(AR) rcs libxlutil.a $^ -xl.o: xl.c +xl.o: xl.c _libxl_types.h $(CC) $(CFLAGS) -c xl.c -xl_cmdimpl.o: xl_cmdimpl.c +xl_cmdimpl.o: xl_cmdimpl.c _libxl_types.h $(CC) $(CFLAGS) -c xl_cmdimpl.c -xl_cmdtable.o: xl_cmdtable.c +xl_cmdtable.o: xl_cmdtable.c _libxl_types.h $(CC) $(CFLAGS) -c xl_cmdtable.c $(CLIENTS): xl.o xl_cmdimpl.o xl_cmdtable.o libxlutil.so libxenlight.so $(CC) $(LDFLAGS) -o $@ $^ $(LIBS) +%.so: _libxl_types.h + .PHONY: install install: all $(INSTALL_DIR) $(DESTDIR)$(SBINDIR)
Re: [PATCH 7 of 8] libxl: generate destructors for each libxl defined type
Quoted 37 lines · Ian Campbell
Thanks for looking over this.
Quoted 6 lines · On Tue, 2010-08-03 at 13:07 +0100, Gianni Tedesco (3P) wrote:
Quoted 3 lines · Ian Campbell
LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o
LIBXL_OBJS= flexarray.o libxl.o libxl_pci.o libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o libxl_internal.o xenguest.o libxl_utils.o $(LIBXL_OBJS-y)
+LIBXL_OBJS +=_libxl_types.cuhm... _libxl_types.o ??
Oops, yes indeed.
Quoted 19 lines
Review libxl_paths.c: _libxl_paths.h · line 61
Quoted 12 lines
AUTOINCS=
libxlu_cfg_y.hlibxlu_cfg_l.h
AUTOSRCS=libxlu_cfg_y.clibxlu_cfg_l.c(quoted diff) +3
-2@@ -54,9 +55,10 @@ libxl_paths.c: _libxl_paths.h libxl.h: _libxl_types.h -_libxl_types.h: gentypes.py libxltypes.py - python gentypes.py __libxl_types.h +_libxl_types.h _libxl_types.c: gentypes.py libxltypes.py + python gentypes.py __libxl_types.h __libxl_types.c mv __libxl_types.h _libxl_types.h + mv __libxl_types.c _libxl_types.cSomething is still wrong in the dep tree that breaks a clean build. I think part of the problem is that the build system cannot find what depends on
_libxl_types.huntil the compile-time-generate dep files are created. On the other hand, it can't create the dep files if the_libxl_types.his not there.Quoted 1 line
Solution is to manually tweak the dep tree, meh:
I thought that the next patch in the series (which adds
_libxl_types.c) also worked around the same problem so I didn't worry too much but I seem to have been mistaken.
Quoted 5 lines
I wonder if this can be wildcarded at all, something like
%.o: _libl_types.h(except not that because it doesn't actually work, AFAICT)
Ian.
Hmm, probably conflicts with higher level Rules.mak thing. Not to mention it may interact badly with $</$^ type of rules. Think my %.so template is a lucky hack tbh. But as long as the dep is added at the top-level (tho not topmost 'all' target level, due to parallelism) it should be fine.
Gianni
PATCH 1/1 xl: free the libxl types contained in struct domain_config
In reply to Ian Campbell# HG changeset patch
# User Ian Campbell <[email protected]>
# Date 1280829842 -3600
# Node ID e977c80592ca15c3bb42edf0a4fcdeb3794543f2 # Parent 6baa8ce2ec5ed5d140a67b87d2514e88464df34e
xl: free the libxl types contained in struct domain_config
Resolves the following leaks found using "valgrind xl create -n ..." (plus presumably others which didn't trigger because I have no devices of that type)
==21241== 5 bytes in 1 blocks are definitely lost in loss record 1 of 6
==21241== at 0x4022F0A: malloc (vg_replace_malloc.c:236) ==21241== by 0x411B22F: strdup (in /lib/i686/cmov/libc-2.7.so) ==21241== by 0x804E56B: parse_config_data (xl_cmdimpl.c:760) ==21241== by 0x8056B04: create_domain (xl_cmdimpl.c:1357) ==21241== by 0x8057ECE: main_create (xl_cmdimpl.c:3154) ==21241== by 0x804B2FB: main (xl.c:76) ==21241== ==21241== 6 bytes in 1 blocks are definitely lost in loss record 2 of 6 ==21241== at 0x4022F0A: malloc (vg_replace_malloc.c:236) ==21241== by 0x411B22F: strdup (in /lib/i686/cmov/libc-2.7.so) ==21241== by 0x804DAAA: parse_config_data (xl_cmdimpl.c:586) ==21241== by 0x8056B04: create_domain (xl_cmdimpl.c:1357) ==21241== by 0x8057ECE: main_create (xl_cmdimpl.c:3154) ==21241== by 0x804B2FB: main (xl.c:76) ==21241== ==21241== 24 bytes in 1 blocks are definitely lost in loss record 3 of 6 ==21241== at 0x4022F0A: malloc (vg_replace_malloc.c:236) ==21241== by 0x411B22F: strdup (in /lib/i686/cmov/libc-2.7.so) ==21241== by 0x804E51F: parse_config_data (xl_cmdimpl.c:754) ==21241== by 0x8056B04: create_domain (xl_cmdimpl.c:1357) ==21241== by 0x8057ECE: main_create (xl_cmdimpl.c:3154) ==21241== by 0x804B2FB: main (xl.c:76) ==21241== ==21241== 27 bytes in 1 blocks are definitely lost in loss record 4 of 6 ==21241== at 0x4022F0A: malloc (vg_replace_malloc.c:236) ==21241== by 0x411B22F: strdup (in /lib/i686/cmov/libc-2.7.so) ==21241== by 0x804DF4A: parse_config_data (xl_cmdimpl.c:664) ==21241== by 0x8056B04: create_domain (xl_cmdimpl.c:1357) ==21241== by 0x8057ECE: main_create (xl_cmdimpl.c:3154) ==21241== by 0x804B2FB: main (xl.c:76) ==21241== ==21241== 28 bytes in 1 blocks are definitely lost in loss record 5 of 6 ==21241== at 0x4022F0A: malloc (vg_replace_malloc.c:236) ==21241== by 0x410C1A7: vasprintf (in /lib/i686/cmov/libc-2.7.so) ==21241== by 0x40EE59A: asprintf (in /lib/i686/cmov/libc-2.7.so) ==21241== by 0x804CA8B: init_nic_info (xl_cmdimpl.c:322) ==21241== by 0x804E6FF: parse_config_data (xl_cmdimpl.c:791) ==21241== by 0x8056B04: create_domain (xl_cmdimpl.c:1357) ==21241== by 0x8057ECE: main_create (xl_cmdimpl.c:3154) ==21241== by 0x804B2FB: main (xl.c:76) ==21241== ==21241== 44 bytes in 1 blocks are definitely lost in loss record 6 of 6 ==21241== at 0x4022F0A: malloc (vg_replace_malloc.c:236) ==21241== by 0x411B22F: strdup (in /lib/i686/cmov/libc-2.7.so) ==21241== by 0x804E168: parse_config_data (xl_cmdimpl.c:694) ==21241== by 0x8056B04: create_domain (xl_cmdimpl.c:1357) ==21241== by 0x8057ECE: main_create (xl_cmdimpl.c:3154) ==21241== by 0x804B2FB: main (xl.c:76)
tools/libxl/libxl_utils.c +2 -2
@@ -81,7 +81,7 @@ int libxl_name_to_domid(libxl_ctx *ctx,return ret; } -char *libxl_poolid_to_name (libxl_ctx *ctx,uint32_t poolid) +const char *libxl_poolid_to_name (libxl_ctx *ctx,uint32_t poolid) {unsigned int len;char path[strlen ("/local/pool" ) +12 ];
@@ -99,7 +99,7 @@ int libxl_name_to_poolid(libxl_ctx *ctx, uint32_t *poolid) {int i, nb_pools; -char *poolname; +const char *poolname;libxl_poolinfo *poolinfo; poolinfo =libxl_list_pool (ctx, &nb_pools);
tools/libxl/libxl_utils.h +1 -1
@@ -22,7 +22,7 @@ int libxl_name_to_domid(libxl_ctx *ctx,int libxl_name_to_domid (libxl_ctx *ctx,const char *name,uint32_t *domid);char *libxl_domid_to_name (libxl_ctx *ctx,uint32_t domid);int libxl_name_to_poolid (libxl_ctx *ctx,const char *name,uint32_t *poolid); -char *libxl_poolid_to_name (libxl_ctx *ctx,uint32_t poolid); +const char *libxl_poolid_to_name (libxl_ctx *ctx,uint32_t poolid);int libxl_get_stubdom_id (libxl_ctx *ctx,int guest_domid);int libxl_is_stubdom (libxl_ctx *ctx,uint32_t domid,uint32_t *target_domid);int libxl_create_logfile (libxl_ctx *ctx,char *name,char **full_name);
tools/libxl/libxltypes.py +1 -1
@@ -232,7 +232,7 @@ libxl_domain_create_info = Struct("domai ("xsdata", KeyValueList(string, string)), ("platformdata", KeyValueList(string, string)), ("poolid", uint32), - ("poolname", string), + ("poolname", string, True), ]) libxl_domain_build_info = Struct("domain_build_info",[
tools/libxl/xl_cmdimpl.c +26 -2
@@ -145,12 +145,34 @@ struct domain_config {static void free_domain_config (struct domain_config *d_config) { +int i; + +for (i=0 ; i<d_config->num_disks; i++) +libxl_device_disk_destroy (&d_config->disks[i]);free (d_config->disks); + +for (i=0 ; i<d_config->num_vifs; i++) +libxl_device_nic_destroy (&d_config->vifs[i]);free (d_config->vifs); + +for (i=0 ; i<d_config->num_vif2s; i++) +libxl_device_net2_destroy (&d_config->vif2s[i]);free (d_config->vif2s); + +for (i=0 ; i<d_config->num_pcidevs; i++) +libxl_device_pci_destroy (&d_config->pcidevs[i]);free (d_config->pcidevs); + +for (i=0 ; i<d_config->num_vfbs; i++) +libxl_device_vfb_destroy (&d_config->vfbs[i]);free (d_config->vfbs); + +for (i=0 ; i<d_config->num_vkbs; i++) +libxl_device_vkb_destroy (&d_config->vkbs[i]);free (d_config->vkbs); + +libxl_domain_create_info_destroy (&d_config->c_info); +libxl_domain_build_info_destroy (&d_config->b_info); }/* Optional data, in order:
@@ -310,7 +332,7 @@ static void init_nic_info(libxl_device_n nic_info->domid =0 ; nic_info->devid = devnum; nic_info->mtu =1492 ; - nic_info->model ="e1000" ; + nic_info->model =strdup ("e1000" ); nic_info->mac[0 ] =0x00 ; nic_info->mac[1 ] =0x16 ; nic_info->mac[2 ] =0x3e ;
@@ -318,7 +340,7 @@ static void init_nic_info(libxl_device_n nic_info->mac[4 ] =1 + (int ) (0xff * (rand () / (RAND_MAX +1.0 ))); nic_info->mac[5 ] =1 + (int ) (0xff * (rand () / (RAND_MAX +1.0 ))); nic_info->ifname =NULL ; - nic_info->bridge ="xenbr0" ; + nic_info->bridge =strdup ("xenbr0" );CHK_ERRNO (asprintf (&nic_info->script,"%s/vif-bridge" ,libxl_xen_script_dir_path ()) ); nic_info->nictype =NICTYPE_IOEMU ;
@@ -800,6 +822,7 @@ static void parse_config_data(const charbreak ; *p2 ='\0' ;if (!strcmp (p,"model" )) { +free (nic->model); nic->model =strdup (p2 +1 ); }else if (!strcmp (p,"mac" )) {char *p3 = p2 +1 ;
@@ -821,6 +844,7 @@ static void parse_config_data(const char *(p3 +2 ) ='\0' ; nic->mac[5 ] =strtol (p3,NULL ,16 ); }else if (!strcmp (p,"bridge" )) { +free (nic->bridge); nic->bridge =strdup (p2 +1 ); }else if (!strcmp (p,"type" )) {if (!strcmp (p2 +1 ,"ioemu" ))
Quoted 9 lines · 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.
Quoted 10 lines
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
Quoted 37 lines · 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.
Quoted 4 lines
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.
Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 0 of 8] [RFC] libxl: autogenerate type definitions and destructor functions"):
Quoted 5 lines
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.
Yes, all excellent stuff, thanks Ian.
Quoted 2 lines
Regarding the memory policy: I am all for explicit freeing by the caller.
Yes.
Ian.
Quoted 8 lines · Ian Jackson
Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 0 of 8] [RFC] libxl: autogenerate type definitions and destructor functions"):
Quoted 5 lines
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.Yes, all excellent stuff, thanks Ian.
OK, I'll rebase (I've been away for a few days and no doubt everything has changed under my feet ;-)) and repost for more in depth review.
Ian.