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

RE: [Xen-devel] Why xs_domain_open() in fs_backend




>-----Original Message-----
>From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx]
>Sent: Wednesday, October 13, 2010 4:48 PM
>To: Jiang, Yunhong
>Cc: samuel.thibault@xxxxxxxxxxxxx; gm281@xxxxxxxxx;
>xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [Xen-devel] Why xs_domain_open() in fs_backend
>
>At 08:19 +0100 on 13 Oct (1286957982), Jiang, Yunhong wrote:
>> Later I noticed that the fs-backend utilize xs_domain_open(), instead
>> of xs_daemon_open(), to communicate with xenstore. grep
>> "xs_domain_open", I noticed it is in fact only used in
>> xenstore_client.c, (xl use it when xs_daemon_open failed, but I
>> suspect if it is really tested), and the xenstore_client.c does not
>> use watch feature at all.
>
>xs_domain_open() is required for xenstore clients to work when they're
>not in the same domain as xenstored (either because xenstore is in a
>stub domain or because the client is not in dom0).  Removing it is
>definitely wrong.

When I firstly checking the code, I also think the xs_domain_open() should be 
more approprate. But it is a bit surprise that it is not used at all, except 
one utility , xentore-client.c , in xenstore directory, which definitely not 
need this (I assume xenstore-ls should always be in same domain as xenstore 
daemon). 
I suspect if xs_domain_open() and the xenfs is really widely tested. Does 
Citrix has any test suite to cover it?

>
>(IMHO xs_daemon_open() should be killed entirely, but there are some
>dom0 kernels where the xs_domain_open() connection isn't allowed to send
>XS_INTRODUCE commands.  That shouldn't make a difference here, though).

But we should at least add xs_domain_close() firstly, matching xs_domain_open() 
with xs_deamon_close() is really something strange :-)

>
>> Following simple patch make it work, but I'm not sure if it is the
>> right method, will fs-backend run in other domain?
>
>What does the change to ROOT_NODE do in this patch?  Any chance that it
>fixes the problem by itself? :)

No, it does not work.

Thanks
--jyh

>
>Cheers,
>
>Tim.
>
>> Thanks
>> --jyh
>>
>> diff -r a33886146b45 tools/fs-back/fs-backend.c
>> --- a/tools/fs-back/fs-backend.c    Fri Oct 08 11:41:57 2010 +0100
>> +++ b/tools/fs-back/fs-backend.c    Wed Oct 13 15:10:22 2010 +0800
>> @@ -462,7 +462,7 @@ int main(void)
>>      sigaction(SIGUSR2, &act, NULL);
>>
>>      /* Open the connection to XenStore first */
>> -    xsh = xs_domain_open();
>> +    xsh = xs_daemon_open();
>>      assert(xsh != NULL);
>>      xs_rm(xsh, XBT_NULL, ROOT_NODE);
>>      /* Create watch node */
>> diff -r a33886146b45 tools/fs-back/fs-backend.h
>> --- a/tools/fs-back/fs-backend.h    Fri Oct 08 11:41:57 2010 +0100
>> +++ b/tools/fs-back/fs-backend.h    Wed Oct 13 15:10:33 2010 +0800
>> @@ -9,7 +9,7 @@
>>  #include <xen/io/fsif.h>
>>  #include "sys-queue.h"
>>
>> -#define ROOT_NODE           "backend/vfs"
>> +#define ROOT_NODE           "/local/domain/0/backend/vfs"
>>  #define EXPORTS_SUBNODE     "exports"
>>  #define EXPORTS_NODE        ROOT_NODE"/"EXPORTS_SUBNODE
>>  #define WATCH_NODE          EXPORTS_NODE"/requests"
>> ~
>> ~
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>
>--
>Tim Deegan <Tim.Deegan@xxxxxxxxxx>
>Principal Software Engineer, XenServer Engineering
>Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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


 


Rackspace

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