WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] [PATCH] docs/misc/xenstore.txt minor fixes

To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH] docs/misc/xenstore.txt minor fixes
From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Date: Wed, 12 Dec 2007 16:16:47 +0000
Delivery-date: Wed, 12 Dec 2007 08:19:06 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Steven Smith has pointed out a few minor errors and provided some more
information about the behaviour of old xenstoreds.  I've documented
the relevant facts, as I understand them, in the attached
documentation patch.

I'm going to follow this up with another patch about size limits for
xenstore messages.

Ian.

Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

diff -r 4553bc1087d9 docs/misc/xenstore.txt
--- a/docs/misc/xenstore.txt    Wed Dec 12 15:41:20 2007 +0000
+++ b/docs/misc/xenstore.txt    Wed Dec 12 16:13:55 2007 +0000
@@ -174,6 +174,17 @@ WATCH                      <wpath>|<token>|?
        away, with <path> equal to <wpath>.  Watches may be triggered
        spuriously.  The tx_id in a WATCH request is ignored.
 
+       Watches are supposed to be restricted by the permissions
+       system but in practice the implementation is imperfect.
+       Applications should not rely on being sent a notification for
+       paths that they cannot read; however, an application may rely
+       on being sent a watch when a path which it _is_ able to read
+       is deleted even if that leaves only a nonexistent unreadable
+       parent.  A notification may omitted if a node's permissions
+       are changed so as to make it unreadable, in which case future
+       notifications may be suppressed (and if the node is later made
+       readable, some notifications may have been lost).
+
 WATCH_EVENT                                    <epath>|<token>|
        Unsolicited `reply' generated for matching modfication events
        as described above.  req_id and tx_id are both 0.
@@ -182,7 +193,7 @@ WATCH_EVENT                                 <epath>|<token>|
        modifed; however if the event was the recursive removal of an
        parent of <wpath>, <epath> is just
        <wpath> (rather than the actual path which was removed).  So
-       <epath> is a child of <epath>, regardless.
+       <epath> is a child of <wpath>, regardless.
 
        Iff <wpath> for the watch was specified as a relative pathname,
        the <epath> path will also be relative (with the same base,
@@ -192,7 +203,7 @@ UNWATCH                     <wpath>|<token>|?
 
 ---------- Transactions ----------
 
-TRANSACTION_START      ??                      <transid>|
+TRANSACTION_START      |                       <transid>|
        <transid> is an opaque uint32_t allocated by xenstored
        represented as unsigned decimal.  After this, transaction may
        be referenced by using <transid> (as 32-bit binary) in the
@@ -202,11 +213,6 @@ TRANSACTION_START  ??                      <transid>|
        Currently xenstored has the bug that after 2^32 transactions
        it will allocate the transid 0 for an actual transaction.
 
-       Clients using the provided xs.c bindings will send a single
-       nul byte for the argument payload.  We recommend that future
-       clients continue to do the same; any future extension will not
-       use that syntax.
-
 TRANSACTION_END                T|
 TRANSACTION_END                F|
        tx_id must refer to existing transaction.  After this
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>