# HG changeset patch
# User Keir Fraser <keir.fraser@xxxxxxxxxx>
# Date 1197627135 0
# Node ID a4fadcab5cb0db5e54d27b10fc721ad7e1e788bd
# Parent 8f0cbfc478d627c89dfa2f76fccc65f614948953
docs/misc/xenstore.txt minor fixes
Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
---
docs/misc/xenstore.txt | 20 +++++++++++++-------
1 files changed, 13 insertions(+), 7 deletions(-)
diff -r 8f0cbfc478d6 -r a4fadcab5cb0 docs/misc/xenstore.txt
--- a/docs/misc/xenstore.txt Thu Dec 13 09:31:03 2007 +0000
+++ b/docs/misc/xenstore.txt Fri Dec 14 10:12:15 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-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog
|
Home