ia64/xen-unstable

changeset 16609:a4fadcab5cb0

docs/misc/xenstore.txt minor fixes
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
author Keir Fraser <keir.fraser@citrix.com>
date Fri Dec 14 10:12:15 2007 +0000 (2007-12-14)
parents 8f0cbfc478d6
children 95bb6485d29d
files docs/misc/xenstore.txt
line diff
     1.1 --- a/docs/misc/xenstore.txt	Thu Dec 13 09:31:03 2007 +0000
     1.2 +++ b/docs/misc/xenstore.txt	Fri Dec 14 10:12:15 2007 +0000
     1.3 @@ -174,6 +174,17 @@ WATCH			<wpath>|<token>|?
     1.4  	away, with <path> equal to <wpath>.  Watches may be triggered
     1.5  	spuriously.  The tx_id in a WATCH request is ignored.
     1.6  
     1.7 +	Watches are supposed to be restricted by the permissions
     1.8 +	system but in practice the implementation is imperfect.
     1.9 +	Applications should not rely on being sent a notification for
    1.10 +	paths that they cannot read; however, an application may rely
    1.11 +	on being sent a watch when a path which it _is_ able to read
    1.12 +	is deleted even if that leaves only a nonexistent unreadable
    1.13 +	parent.  A notification may omitted if a node's permissions
    1.14 +	are changed so as to make it unreadable, in which case future
    1.15 +	notifications may be suppressed (and if the node is later made
    1.16 +	readable, some notifications may have been lost).
    1.17 +
    1.18  WATCH_EVENT					<epath>|<token>|
    1.19  	Unsolicited `reply' generated for matching modfication events
    1.20  	as described above.  req_id and tx_id are both 0.
    1.21 @@ -182,7 +193,7 @@ WATCH_EVENT					<epath>|<token>|
    1.22  	modifed; however if the event was the recursive removal of an
    1.23  	parent of <wpath>, <epath> is just
    1.24  	<wpath> (rather than the actual path which was removed).  So
    1.25 -	<epath> is a child of <epath>, regardless.
    1.26 +	<epath> is a child of <wpath>, regardless.
    1.27  
    1.28  	Iff <wpath> for the watch was specified as a relative pathname,
    1.29  	the <epath> path will also be relative (with the same base,
    1.30 @@ -192,7 +203,7 @@ UNWATCH			<wpath>|<token>|?
    1.31  
    1.32  ---------- Transactions ----------
    1.33  
    1.34 -TRANSACTION_START	??			<transid>|
    1.35 +TRANSACTION_START	|			<transid>|
    1.36  	<transid> is an opaque uint32_t allocated by xenstored
    1.37  	represented as unsigned decimal.  After this, transaction may
    1.38  	be referenced by using <transid> (as 32-bit binary) in the
    1.39 @@ -202,11 +213,6 @@ TRANSACTION_START	??			<transid>|
    1.40  	Currently xenstored has the bug that after 2^32 transactions
    1.41  	it will allocate the transid 0 for an actual transaction.
    1.42  
    1.43 -	Clients using the provided xs.c bindings will send a single
    1.44 -	nul byte for the argument payload.  We recommend that future
    1.45 -	clients continue to do the same; any future extension will not
    1.46 -	use that syntax.
    1.47 -
    1.48  TRANSACTION_END		T|
    1.49  TRANSACTION_END		F|
    1.50  	tx_id must refer to existing transaction.  After this