[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 5/5] libxl: clean xenstore console directories recursively on destroy



On Mon, 2012-04-16 at 16:06 +0100, Roger Pau Monne wrote:
> Clean xenstore, to prevent leaving empty directories in the tree, like:
> 
> /local/domain/0/backend/console = ""   (n0)
> /local/domain/0/backend/console/3 = ""   (n0)
> 
> That was left after a guest was destroyed.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@xxxxxxxxxx>
> ---
>  tools/libxl/libxl_device.c |    5 ++---
>  1 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index d773d71..4161d1bd 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -609,12 +609,11 @@ out_ok:
>  
>  int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
>  {
> -    libxl_ctx *ctx = libxl__gc_owner(gc);
>      char *be_path = libxl__device_backend_path(gc, dev);
>      char *fe_path = libxl__device_frontend_path(gc, dev);
>  
> -    xs_rm(ctx->xsh, XBT_NULL, be_path);
> -    xs_rm(ctx->xsh, XBT_NULL, fe_path);
> +    libxl__xs_path_cleanup(gc, fe_path);
> +    libxl__xs_path_cleanup(gc, be_path);

is xs_rm not recursive? At least from the CLI it seems to be

quartz:~# xenstore-write /foo/bar/baz 123
quartz:~# xenstore-ls -f | grep foo
/foo = ""
/foo/bar = ""
/foo/bar/baz = "123"
quartz:~# xenstore-rm  /foo
quartz:~# xenstore-ls -f | grep foo
quartz:~# 

looking at xenstore_client.c it seems to only call xs_rm() and not do
any traversal itself?

>  
>      libxl__device_destroy_tapdisk(gc, be_path);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.