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