Mailing List Archive

[PATCH 13/15] libxl: make LIBXL_INIT_GC a statement, not an initialiser
Previously LIBXL_INIT_GC was an initialiser, which you were expected
to use like this:
libxl__gc gc = LIBXL_INIT_GC(ctx);

But we are going to want to put things in the gc which are to be
initialised using other macros. That means that LIBXL_INIT_GC has to
become a statement too. So instead, we make it so that it's used like this:
libxl_gc gc;
LIBXL_INIT_GC(gc,ctx);

In fact there is only one caller now, GC_INIT, which uses this trick:
libxl_gc gc[1];
LIBXL_INIT_GC(gc[0],ctx);

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
tools/libxl/libxl_internal.h | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1d1dc35..d015c7c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -145,7 +145,12 @@ typedef struct {
libxl_ctx *owner;
} libxl__gc;

-#define LIBXL_INIT_GC(ctx) (libxl__gc){ .alloc_maxsize = 0, .alloc_ptrs = 0, .owner = ctx }
+#define LIBXL_INIT_GC(gc,ctx) do{ \
+ (gc).alloc_maxsize = 0; \
+ (gc).alloc_ptrs = 0; \
+ (gc).owner = (ctx); \
+ } while(0)
+
static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
{
return gc->owner;
@@ -676,7 +681,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
* as a local variable.
*/

-#define GC_INIT(ctx) libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
+#define GC_INIT(ctx) libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
#define GC_FREE libxl__free_all(gc)
#define CTX libxl__gc_owner(gc)

--
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH 13/15] libxl: make LIBXL_INIT_GC a statement, not an initialiser [ In reply to ]
On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> Previously LIBXL_INIT_GC was an initialiser, which you were expected
> to use like this:
> libxl__gc gc = LIBXL_INIT_GC(ctx);
>
> But we are going to want to put things in the gc which are to be
> initialised using other macros. That means that LIBXL_INIT_GC has to
> become a statement too. So instead, we make it so that it's used like this:
> libxl_gc gc;
> LIBXL_INIT_GC(gc,ctx);
>
> In fact there is only one caller now, GC_INIT,

Maybe we should just fold LIBXL_INIT_GC into GC_INIT then?

> which uses this trick:
> libxl_gc gc[1];
> LIBXL_INIT_GC(gc[0],ctx);

Ian.

>
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
> tools/libxl/libxl_internal.h | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 1d1dc35..d015c7c 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -145,7 +145,12 @@ typedef struct {
> libxl_ctx *owner;
> } libxl__gc;
>
> -#define LIBXL_INIT_GC(ctx) (libxl__gc){ .alloc_maxsize = 0, .alloc_ptrs = 0, .owner = ctx }
> +#define LIBXL_INIT_GC(gc,ctx) do{ \
> + (gc).alloc_maxsize = 0; \
> + (gc).alloc_ptrs = 0; \
> + (gc).owner = (ctx); \
> + } while(0)
> +
> static inline libxl_ctx *libxl__gc_owner(libxl__gc *gc)
> {
> return gc->owner;
> @@ -676,7 +681,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
> * as a local variable.
> */
>
> -#define GC_INIT(ctx) libxl__gc gc[1] = { LIBXL_INIT_GC(ctx) }
> +#define GC_INIT(ctx) libxl__gc gc[1]; LIBXL_INIT_GC(gc[0],ctx)
> #define GC_FREE libxl__free_all(gc)
> #define CTX libxl__gc_owner(gc)
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH 13/15] libxl: make LIBXL_INIT_GC a statement, not an initialiser [ In reply to ]
Ian Campbell writes ("Re: [Xen-devel] [PATCH 13/15] libxl: make LIBXL_INIT_GC a statement, not an initialiser"):
> On Mon, 2011-12-05 at 18:10 +0000, Ian Jackson wrote:
> > In fact there is only one caller now, GC_INIT,
>
> Maybe we should just fold LIBXL_INIT_GC into GC_INIT then?

No, because GC_INIT is a non-hygienic convenience macro. Such things
should never be the only implementation of some important interface,
because then if for any reason the lack of hygiene is a problem for
you you are stuck.

LIBXL_INIT_GC is the underlying functionality which may need to be
used in those other, less usual cases, and therefore still needs to
exist as a separate interface.

Indeed in my asynchronous operations code (patch(es) still very much a
work in progress) I will need to call LIBXL_INIT_GC outside GC_INIT.

Ian.

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