[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |