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

[Roger Pau Monne <roger.pau@xxxxxxxxxx>]

El 16/04/2012, a las 17:50, Ian Campbell escribió:
> 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?


Sure! I had an error probably somewhere else in the code, and changing 
libxl__xs_path_cleanup to xs_rm didn't make it happen again, so forget about 
this. I will send an updated version of the series without this stuff (and the 
appropriate changes).

> 
>> 
>>     libxl__device_destroy_tapdisk(gc, be_path);
>> 
> 
> 



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