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

Roger Pau Monne
Tue, 17 Apr 2012 14:32:26 -0000

El 17/04/2012, a las 15:18, Roger Pau Monne escribió:
> On Tue, 2012-04-17 at 15:18 +0100, Roger Pau Monne wrote:
>> 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@citrix.com>
>>>> ---
>>>> 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
>>
>> Ok, I got messed up here, what my function did was purge a directory
>> tree from top to bottom, so using your example, doing a:
>>
>> libxl__xs_path_cleanup(gc, "/foo/bar/baz");
>>
>> Would have erased /foo/bar/baz, /foo/bar and /foo, because they where
>> all empty (had no more files or subfolders inside) after deleting
>> "baz".
>
> IFF they are empty? So the presence of /foo/bob would have made
> only /foo/bar/baz and /foo/bar but not /foo get deleted?


Yes, if there''s a /foo/bob that would prevent the deletion of /foo.

>
> IOW it behaves like "xenstore-rm -t" (t for tidy)?

From what I saw, yes (although I didn''t even know of "xenstore-rm
-t").

>
>>
>> So I guess this is really needed.
>>
>>>
>>> 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);
>>>>
>>>
>>>
>>
>>
>
>