I always get error on fs-backend when I was trying the stubdomain. The error is
either " fs-backend: xenbus_get_watch_fd: could not setup watch: Invalid
argument" or "fs-backend: xenbus_get_watch_fd: could not setup watch:
Bad file descriptor".
I tried to debug it, seems it failed when fs-backend access the /proc/xen/xenbus
file to setup a watch. It failed either because write the file failed or read
the reply back failed. Further investigation does not make much progress.
(I''m using PVops dom0 and latest upstream xen).
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.
Following simple patch make it work, but I''m not sure if it is the
right method, will fs-backend run in other domain?
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@lists.xensource.com
http://lists.xensource.com/xen-devel
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. (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).> 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? :) 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@lists.xensource.com > http://lists.xensource.com/xen-devel-- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, XenServer Engineering Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>-----Original Message----- >From: Tim Deegan [mailto:Tim.Deegan@citrix.com] >Sent: Wednesday, October 13, 2010 4:48 PM >To: Jiang, Yunhong >Cc: samuel.thibault@eu.citrix.com; gm281@cam.ac.uk; >xen-devel@lists.xensource.com >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@lists.xensource.com >> http://lists.xensource.com/xen-devel > >-- >Tim Deegan <Tim.Deegan@citrix.com> >Principal Software Engineer, XenServer Engineering >Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
At 10:13 +0100 on 13 Oct (1286964818), Jiang, Yunhong wrote:> 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.I had thought it was used by stubdom qemu, but it seems not - not sure how that works then. It isn''t specifically tested but I know that some people have been using it successfully in the last month or two.> > > >(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 :-)I think the right thing to do would be have xs_daemon_open hide the details of whether the connection is over a socket or xenbus, and not have every caller have to care about that. In the meantime if the domain connection isn''t working for you, you could always copy the logic from libxl of trying daemon first. Tim.> >> 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@lists.xensource.com > >> http://lists.xensource.com/xen-devel > > > >-- > >Tim Deegan <Tim.Deegan@citrix.com> > >Principal Software Engineer, XenServer Engineering > >Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)-- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, XenServer Engineering Citrix Systems UK Ltd. (Company #02937203, SL9 0BG) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stefano Stabellini
2010-Oct-13 10:30 UTC
Re: [Xen-devel] Why xs_domain_open() in fs_backend
On Wed, 13 Oct 2010, Tim Deegan wrote:> At 10:13 +0100 on 13 Oct (1286964818), Jiang, Yunhong wrote: > > 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. > > I had thought it was used by stubdom qemu, but it seems not - not sure > how that works then. It isn''t specifically tested but I know that some > people have been using it successfully in the last month or two. >minios exports xs_daemon_open and xs_daemon_close> > > > > >(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 :-) > > I think the right thing to do would be have xs_daemon_open hide the > details of whether the connection is over a socket or xenbus, and not > have every caller have to care about that. >ditto _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>-----Original Message----- >From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com] >Sent: Wednesday, October 13, 2010 6:31 PM >To: Tim Deegan >Cc: Jiang, Yunhong; xen-devel@lists.xensource.com; gm281@cam.ac.uk; >samuel.thibault@eu.citrix.com >Subject: Re: [Xen-devel] Why xs_domain_open() in fs_backend > >On Wed, 13 Oct 2010, Tim Deegan wrote: >> At 10:13 +0100 on 13 Oct (1286964818), Jiang, Yunhong wrote: >> > 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. >> >> I had thought it was used by stubdom qemu, but it seems not - not sure >> how that works then. It isn''t specifically tested but I know that some >> people have been using it successfully in the last month or two.But are their ussage covers the xs_watch? Seems xs_read/xs_write works well in the fs-backend utility. Only xs_watch has such issue.>> > >minios exports xs_daemon_open and xs_daemon_closeThe minios implementation seems a bit different. In fact, I''m very confused why fs-backend failed on my environment. It is a tools for stubdom qemu and I assume it should be used by a lot of people, and I didn''t google out any complain on this issue. Maybe my environment cause such issue? Can anyone else have a try also? Simply input "fs-backend" should invoke it. Thanks --jyh> > >> > > >> > >(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 :-) >> >> I think the right thing to do would be have xs_daemon_open hide the >> details of whether the connection is over a socket or xenbus, and not >> have every caller have to care about that. >> > >ditto > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2010-10-13 at 08:19 +0100, Jiang, Yunhong wrote:> the xenstore_client.c does not use watch feature at all.I''ve occasionally thought that it might be useful to have a xenstore-watch command for skanky scripting purposes so below is a patch to add one. I don''t know how useful it is generally but it can be used to shows that "xenstore-watch -s x" (i.e. xs_daemon_open) does appear to be broken. Subject: xenstore: add xenstore-watch command line client # xenstore-watch x | while read w ; do> echo "watch fired on $w" > echo "value" $(xenstore-read $w) > echo > done# xenstore-write x/y/z 42 output from while loop: watch fired on x/t/z value 42 Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 0b69bd41cf15 tools/xenstore/Makefile --- a/tools/xenstore/Makefile Wed Oct 13 13:47:32 2010 +0100 +++ b/tools/xenstore/Makefile Wed Oct 13 13:56:08 2010 +0100 @@ -9,7 +9,7 @@ CFLAGS += $(CFLAGS_libxenctrl) CFLAGS += $(CFLAGS_libxenctrl) CLIENTS := xenstore-exists xenstore-list xenstore-read xenstore-rm xenstore-chmod -CLIENTS += xenstore-write xenstore-ls +CLIENTS += xenstore-write xenstore-ls xenstore-watch XENSTORED_OBJS = xenstored_core.o xenstored_watch.o xenstored_domain.o xenstored_transaction.o xs_lib.o talloc.o utils.o tdb.o hashtable.o diff -r 0b69bd41cf15 tools/xenstore/xenstore_client.c --- a/tools/xenstore/xenstore_client.c Wed Oct 13 13:47:32 2010 +0100 +++ b/tools/xenstore/xenstore_client.c Wed Oct 13 13:56:08 2010 +0100 @@ -36,6 +36,7 @@ enum mode { MODE_read, MODE_rm, MODE_write, + MODE_watch, }; static char *output_buf = NULL; @@ -95,6 +96,9 @@ usage(enum mode mode, int incl_mode, con case MODE_chmod: mstr = incl_mode ? "chmod " : ""; errx(1, "Usage: %s %s[-h] [-u] [-r] [-s] key <mode [modes...]>", progname, mstr); + case MODE_watch: + mstr = incl_mode ? "watch " : ""; + errx(1, "Usage: %s %s[-h] [-n NR] key", progname, mstr); } } @@ -263,9 +267,28 @@ do_chmod(char *path, struct xs_permissio } } +static void +do_watch(struct xs_handle *xsh, int max_events) +{ + int count = 0; + char **vec = NULL; + + for ( count = 0; max_events == -1 || count < max_events; count++ ) { + unsigned int num; + + vec = xs_read_watch(xsh, &num); + if (vec == NULL) + continue; + + printf("%s\n", vec[XS_WATCH_PATH]); + fflush(stdout); + free(vec); + } +} + static int perform(enum mode mode, int optind, int argc, char **argv, struct xs_handle *xsh, - xs_transaction_t xth, int prefix, int tidy, int upto, int recurse) + xs_transaction_t xth, int prefix, int tidy, int upto, int recurse, int nr_watches) { switch (mode) { case MODE_ls: @@ -428,6 +451,15 @@ perform(enum mode mode, int optind, int do_chmod(path, perms, nperms, upto, recurse, xsh, xth); break; } + case MODE_watch: { + for (; argv[optind]; optind++) { + const char *w = argv[optind]; + + if (!xs_watch(xsh, w, w)) + errx(1, "Unable to add watch on %s\n", w); + } + do_watch(xsh, nr_watches); + } } } @@ -452,6 +484,8 @@ static enum mode lookup_mode(const char return MODE_write; else if (strcmp(m, "read") == 0) return MODE_read; + else if (strcmp(m, "watch") == 0) + return MODE_watch; errx(1, "unknown mode %s\n", m); return 0; @@ -467,6 +501,7 @@ main(int argc, char **argv) int tidy = 0; int upto = 0; int recurse = 0; + int nr_watches = -1; int transaction; struct winsize ws; enum mode mode; @@ -500,10 +535,11 @@ main(int argc, char **argv) {"tidy", 0, 0, ''t''}, /* MODE_rm */ {"upto", 0, 0, ''u''}, /* MODE_chmod */ {"recurse", 0, 0, ''r''}, /* MODE_chmod */ + {"number", 1, 0, ''n''}, /* MODE_watch */ {0, 0, 0, 0} }; - c = getopt_long(argc - switch_argv, argv + switch_argv, "hfsptur", + c = getopt_long(argc - switch_argv, argv + switch_argv, "hfspturn:", long_options, &index); if (c == -1) break; @@ -548,6 +584,12 @@ main(int argc, char **argv) else usage(mode, switch_argv, argv[0]); break; + case ''n'': + if ( mode == MODE_watch ) + nr_watches = atoi(optarg); + else + usage(mode, switch_argv, argv[0]); + break; } } @@ -575,6 +617,7 @@ main(int argc, char **argv) transaction = (argc - switch_argv - optind) > 2; break; case MODE_ls: + case MODE_watch: transaction = 0; break; default: @@ -601,7 +644,7 @@ again: errx(1, "couldn''t start transaction"); } - ret = perform(mode, optind, argc - switch_argv, argv + switch_argv, xsh, xth, prefix, tidy, upto, recurse); + ret = perform(mode, optind, argc - switch_argv, argv + switch_argv, xsh, xth, prefix, tidy, upto, recurse, nr_watches); if (transaction && !xs_transaction_end(xsh, xth, ret)) { if (ret == 0 && errno == EAGAIN) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2010-10-13 at 13:57 +0100, Ian Campbell wrote:> > I don''t know how useful it is generally but it can be used to shows > that "xenstore-watch -s x" (i.e. xs_daemon_open) does appear to be > broken.Actually this is backwards and I seem to be seeing the exact opposite to you. IOW for me: "xenstore-watch x" -> xs_domain_open() -- works "xenstore-watch -s x" -> xs_daemon_open() -- does not work, XS_ERROR reply from daemon Can you confirm which version fails for you? It also seems to be specific to the C xenstored, the ocaml oxenstored works fine. Lastly it seems to be a problem with relative paths only, absolute paths seem to be ok. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2010-10-13 at 14:18 +0100, Ian Campbell wrote:> On Wed, 2010-10-13 at 13:57 +0100, Ian Campbell wrote: > > > > I don''t know how useful it is generally but it can be used to shows > > that "xenstore-watch -s x" (i.e. xs_daemon_open) does appear to be > > broken. > > Actually this is backwards and I seem to be seeing the exact opposite to > you. IOW for me: > > "xenstore-watch x" -> xs_domain_open() -- works > "xenstore-watch -s x" -> xs_daemon_open() -- does not work, XS_ERROR reply from daemon > > Can you confirm which version fails for you? > > It also seems to be specific to the C xenstored, the ocaml oxenstored > works fine. > > Lastly it seems to be a problem with relative paths only, absolute paths > seem to be ok.This appears to be deliberate. xenstore clients connecting via the socket interface have no implicit /local/domain/<domid> home directory. (see xenstored_core.c:canonicalize and its use from xenstored_watch.c:do_watch) and therefore must use absolute paths. The ocaml xenstored works around this by assuming that socket connections originate in domain 0, which is a little dubious if oxenstored is running in a stub domain but in that case there is no userspace and hence no clients using the socket interface, so it is fine. The only problem I see is that it uses whatever random errno happens to be current in the error message. Ian. # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1286977342 -3600 # Node ID 78f2c9b4d902fa04f7055012c63d6dd24e823da0 # Parent 9a5a576bcc8ae17f19c9f89b73a026a0acfb5cf1 xenstored: return EINVAL for attempt to watch invalid path errno is essentially random at this point. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 9a5a576bcc8a -r 78f2c9b4d902 tools/xenstore/xenstored_watch.c --- a/tools/xenstore/xenstored_watch.c Wed Oct 13 13:56:12 2010 +0100 +++ b/tools/xenstore/xenstored_watch.c Wed Oct 13 14:42:22 2010 +0100 @@ -134,7 +134,7 @@ void do_watch(struct connection *conn, s relative = !strstarts(vec[0], "/"); vec[0] = canonicalize(conn, vec[0]); if (!is_valid_nodename(vec[0])) { - send_error(conn, errno); + send_error(conn, EINVAL); return; } } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2010-10-13 at 10:13 +0100, Jiang, Yunhong wrote:> (I assume xenstore-ls should always be in same domain as xenstore > daemon).The xenstore clients work fine in any domain which exports a /proc/xen/xenbus interface to userspace, subject to the user running them having sufficient guest privilege to access the magic device and subject to the permissions within xenstore allowing the domain to list the directories in question etc. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>-----Original Message----- >From: Ian Campbell [mailto:Ian.Campbell@citrix.com] >Sent: Wednesday, October 13, 2010 9:53 PM >To: Jiang, Yunhong >Cc: Tim Deegan; xen-devel@lists.xensource.com; gm281@cam.ac.uk; >samuel.thibault@eu.citrix.com >Subject: RE: [Xen-devel] Why xs_domain_open() in fs_backend > >On Wed, 2010-10-13 at 10:13 +0100, Jiang, Yunhong wrote: >> (I assume xenstore-ls should always be in same domain as xenstore >> daemon). > >The xenstore clients work fine in any domain which exports >a /proc/xen/xenbus interface to userspace, subject to the user running >them having sufficient guest privilege to access the magic device and >subject to the permissions within xenstore allowing the domain to list >the directories in question etc.Thanks for clasification. --jyh> >Ian._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
The result in my side is: [root@vt_wb_jimmy xen-unstable]# xenstore-watch -s /local/domain/0/a/b | while read w ; do echo "watch fired on $w"; echo "value" $(xenstore-read $w); echo; done watch fired on /local/domain/0/a/b value watch fired on /local/domain/0/a/b/c/defe value 44 watch fired on /local/domain/0/a/b/c/defe value 45 [root@vt_wb_jimmy xen-unstable]# xenstore-watch /local/domain/0/a/b | while read w ; do echo "watch fired on $w"; echo "value" $(xenstore-read $w); echo; done xenstore-watch: Unable to add watch on /local/domain/0/a/b One thing need notice is, the first time when I use xenstore-watch without -s, it will not fail with "Unable to add watch on ....", instead, it will simply not print anything when I change the a/b/c/defe value, then I ctrl-c to kill it. Next time it will fail with "Unable to add watch on ...", as log below. Hope this will be helpful. BTW, what's your dom0 version? [root@vt_wb_jimmy xen-unstable]# xenstore-watch /local/domain/0/a/b | while read w ; do echo "watch fired on $w"; echo "value" $(xenstore-read $w); echo; done watch fired on /local/domain/0/a/b value ^C >>>>>>>>>>>>>>>>>>I press ctrl-c here because it does not print anythine while I change the a/b/c/defe in another console. [root@vt_wb_jimmy xen-unstable]# xenstore-watch /local/domain/0/a/b | while read w ; do echo "watch fired on $w"; echo "value" $(xenstore-read $w); echo; done xenstore-watch: Unable to add watch on /local/domain/0/a/b Thanks --jyh>-----Original Message----->From: Ian Campbell [mailto:Ian.Campbell@citrix.com]>Sent: Wednesday, October 13, 2010 9:48 PM>To: Jiang, Yunhong>Cc: xen-devel@lists.xensource.com; gm281@cam.ac.uk>Subject: Re: [Xen-devel] Why xs_domain_open() in fs_backend>>On Wed, 2010-10-13 at 14:18 +0100, Ian Campbell wrote:>> On Wed, 2010-10-13 at 13:57 +0100, Ian Campbell wrote:>> >>> > I don't know how useful it is generally but it can be used to shows>> > that "xenstore-watch -s x" (i.e. xs_daemon_open) does appear to be>> > broken.>>>> Actually this is backwards and I seem to be seeing the exact opposite to>> you. IOW for me:>>>> "xenstore-watch x" -> xs_domain_open() -- works>> "xenstore-watch -s x" -> xs_daemon_open() -- does not work, XS_ERROR reply>from daemon>>>> Can you confirm which version fails for you?>>>> It also seems to be specific to the C xenstored, the ocaml oxenstored>> works fine.>>>> Lastly it seems to be a problem with relative paths only, absolute paths>> seem to be ok.>>This appears to be deliberate. xenstore clients connecting via the>socket interface have no implicit /local/domain/<domid> home directory.>(see xenstored_core.c:canonicalize and its use from>xenstored_watch.c:do_watch) and therefore must use absolute paths. The>ocaml xenstored works around this by assuming that socket connections>originate in domain 0, which is a little dubious if oxenstored is>running in a stub domain but in that case there is no userspace and>hence no clients using the socket interface, so it is fine.>>The only problem I see is that it uses whatever random errno happens to>be current in the error message.>>Ian.>># HG changeset patch># User Ian Campbell <ian.campbell@citrix.com>># Date 1286977342 -3600># Node ID 78f2c9b4d902fa04f7055012c63d6dd24e823da0># Parent 9a5a576bcc8ae17f19c9f89b73a026a0acfb5cf1>xenstored: return EINVAL for attempt to watch invalid path>>errno is essentially random at this point.>>Signed-off-by: Ian Campbell <ian.campbell@citrix.com>>>diff -r 9a5a576bcc8a -r 78f2c9b4d902 tools/xenstore/xenstored_watch.c>--- a/tools/xenstore/xenstored_watch.c Wed Oct 13 13:56:12 2010 +0100>+++ b/tools/xenstore/xenstored_watch.c Wed Oct 13 14:42:22 2010 +0100>@@ -134,7 +134,7 @@ void do_watch(struct connection *conn, s> relative = !strstarts(vec[0], "/");> vec[0] = canonicalize(conn, vec[0]);> if (!is_valid_nodename(vec[0])) {>- send_error(conn, errno);>+ send_error(conn, EINVAL);> return;> }> }>_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2010-10-13 at 15:04 +0100, Jiang, Yunhong wrote:> [root@vt_wb_jimmy xen-unstable]# xenstore-watch /local/domain/0/a/b | > while read w ; do echo "watch fired on $w"; echo "value" > $(xenstore-read $w); echo; done xenstore-watch: Unable to add watch > on /local/domain/0/a/b > > > > One thing need notice is, the first time when I use xenstore-watch > without -s, it will not fail with "Unable to add watch on ....", > instead, it will simply not print anything when I change the > a/b/c/defe value, then I ctrl-c to kill it. Next time it will fail > with "Unable to add watch on ...", as log below. Hope this will be > helpful.Very strange indeed.> BTW, what''s your dom0 version?Pretty recent xen.git, I don''t have a specific changeset but I think it is around 56b5a161fd2f8b13a47497bac7c9e5d1e446ffc6. Which dom0 kernel and what version are you using? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>-----Original Message----- >From: Ian Campbell [mailto:Ian.Campbell@eu.citrix.com] >Sent: Wednesday, October 13, 2010 11:35 PM >To: Jiang, Yunhong >Cc: xen-devel@lists.xensource.com; gm281@cam.ac.uk >Subject: RE: [Xen-devel] Why xs_domain_open() in fs_backend > >On Wed, 2010-10-13 at 15:04 +0100, Jiang, Yunhong wrote: >> [root@vt_wb_jimmy xen-unstable]# xenstore-watch /local/domain/0/a/b | >> while read w ; do echo "watch fired on $w"; echo "value" >> $(xenstore-read $w); echo; done xenstore-watch: Unable to add watch >> on /local/domain/0/a/b >> >> >> >> One thing need notice is, the first time when I use xenstore-watch >> without -s, it will not fail with "Unable to add watch on ....", >> instead, it will simply not print anything when I change the >> a/b/c/defe value, then I ctrl-c to kill it. Next time it will fail >> with "Unable to add watch on ...", as log below. Hope this will be >> helpful. > >Very strange indeed. > >> BTW, what's your dom0 version? > >Pretty recent xen.git, I don't have a specific changeset but I think it >is around 56b5a161fd2f8b13a47497bac7c9e5d1e446ffc6. > >Which dom0 kernel and what version are you using?I' using xen/master branch in pvops : [root@vt_wb_jimmy linux-2.6-pvops.git]# git branch origin/xen/stable-2.6.32.x * xen/master xen/master.stgit [root@vt_wb_jimmy linux-2.6-pvops.git]# git log -v |head -n 20 commit 641c127b67b3b1a4f6a79b6189ed2189cec46012 Merge: 5f8784c... a389e98... Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Date: Tue Jul 6 16:04:30 2010 -0700 Merge commit 'v2.6.31.14' into xen/stable-2.6.31.x * commit 'v2.6.31.14': Linux 2.6.31.14 posix_timer: Fix error path in timer_create reiserfs: fix corruption during shrinking of xattrs reiserfs: fix permissions on .reiserfs_priv ALSA: mixart: range checking proc file commit a389e98d2c6e1900f035befe215f541436bcb0b2 Author: Greg Kroah-Hartman <gregkh@suse.de> Date: Mon Jul 5 10:11:43 2010 -0700 Linux 2.6.31.14 Thanks --jyh> >Ian. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, 2010-10-15 at 03:29 +0100, Jiang, Yunhong wrote:> >Which dom0 kernel and what version are you using? > > I'' using xen/master branch in pvops :That branch is essentially a deadend based on upstream 2.6.31. I''d strongly recommend you move to the xen/stable-2.6.32.x branch which is the current stable branch. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Oops. I will do that and try later. Thanks --jyh>-----Original Message----- >From: Ian Campbell [mailto:Ian.Campbell@eu.citrix.com] >Sent: Friday, October 15, 2010 2:49 PM >To: Jiang, Yunhong >Cc: xen-devel@lists.xensource.com >Subject: RE: [Xen-devel] Why xs_domain_open() in fs_backend > >On Fri, 2010-10-15 at 03:29 +0100, Jiang, Yunhong wrote: > >> >Which dom0 kernel and what version are you using? >> >> I'' using xen/master branch in pvops : > >That branch is essentially a deadend based on upstream 2.6.31. I''d >strongly recommend you move to the xen/stable-2.6.32.x branch which is >the current stable branch. > >Ian._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell writes ("Re: [Xen-devel] Why xs_domain_open() in
fs_backend"):> xenstored: return EINVAL for attempt to watch invalid path
> errno is essentially random at this point.
Applied, thanks.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Campbell writes ("Re: [Xen-devel] Why xs_domain_open() in
fs_backend"):> Subject: xenstore: add xenstore-watch command line client
Thanks, after reading the discussion it seems that we are agreed that
this is correct. So I have applied it.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel