This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: RE: [Xen-devel] Why xs_domain_open() in fs_backend
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Wed, 13 Oct 2010 22:04:06 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "gm281@xxxxxxxxx" <gm281@xxxxxxxxx>
Delivery-date: Wed, 13 Oct 2010 07:05:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1286977656.2003.3346.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <789F9655DD1B8F43B48D77C5D30659732F9D7EBD@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1286974627.2003.3294.camel@xxxxxxxxxxxxxxxxxxxxxx> <1286975935.2003.3310.camel@xxxxxxxxxxxxxxxxxxxxxx> <1286977656.2003.3346.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Actq3TWsTx/xNUJsTXqy7EowScjVQgAAbB8A
Thread-topic: [Xen-devel] Why xs_domain_open() in fs_backend

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





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






^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






>-----Original Message-----

>From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx]

>Sent: Wednesday, October 13, 2010 9:48 PM

>To: Jiang, Yunhong

>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; gm281@xxxxxxxxx

>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.




># HG changeset patch

># User Ian Campbell <ian.campbell@xxxxxxxxxx>

># 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@xxxxxxxxxx>


>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