Parsing/generating the escape sequences used by xenstore-client is non
trivial. So make scripting (for use in stubdom) easier by adding a raw
option.
[added man page entries, facor out expand_buffer]
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Coverity uses several heuristics to identify when one case statement
legitimately falls through into the next, and a comment as the final item in a
case statement is one heuristic (the assumption being that it is a
justification for the fallthrough).
Use this to perform an audit of defects and hide the legitimate fallthroughs.
There are two bugfixes identified in the audit, both minor:
* 'n' command line handling for gtracestat
* BKSPC handling in xentop
All other identified defaults are legitimate fallthoughs
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Coverity-IDs: 1055464, 1055465, 1055467, 1055468, 1055481, 1055482
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Xen Coverity Team <coverity@xen.org>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Don Koch <dkoch@verizon.com>
do_ls is recursive. It had a buffer of size around 5K allocated on
the stack. This combination is not a very good idea: some
environments (eg, Mini-OS) have limited stack sizes (eg 64K).
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Constant MAX_PERMS 16 is too small to use in some occasions, e.g. if
there are more than 16 domU(s) on one hypervisor (it's easy to
achieve) and one wants to do xenstore-chmod PATH to all domU(s). So,
remove MAX_PERMS limitation and make it as arbitrary number of perms.
Signed-off-by: Chunyan Liu <cyliu@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
The xenstore header xs.h is producing conflicts with other software[1].
xs is a too short identifier and does not matche the library. Renaming
the headers to xenstore.h and xenstore_lib.h is the easiest way to make
them easy recognizable and prevent furthe problems.
[1]: http://bugs.debian.org/668550
[ Also update QEMU_TAG, to bring in corresponding change to
qemu-xen-traditional. -iwj ]
Signed-off-by: Bastian Blank <waldi@debian.org>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
--HG--
rename : tools/xenstore/xs.h => tools/xenstore/xenstore.h
rename : tools/xenstore/xs_lib.h => tools/xenstore/xenstore_lib.h
The "-s" option to xenstore-ls is used by the xencommons startup
script to check whether xenstored is already running, before starting
it.
Since 22498:a40455ae9ad3, "-s" has been a no-op, and libxenstore will
always fall back to using xenbus. The combined effect is that the
xencommons script deadlocks: xenstore-ls hangs waiting for xenstored,
which isn't started by xencommons because xencommons is waiting for
xenstore-ls.
In this patch, we:
* Introduce a new XS_OPEN_SOCKETONLY flag which disables the
fallback behaviour;
* Make the xenstore command line tools use the new xs_open call
rather than the old, deprecated xs_open_* calls (which are
now identical).
* Plumb the xenstore command line tools "-s" option to set the
XS_OPEN_SOCKETONLY flag.
* Change the type of the XS_OPEN_* flags so that they naturally have
type unsigned long.
The "-s" option to xenstore-ls et al, and the XS_OPEN_SOCKETONLY flag,
are intended for use by toolstack infrastructure and should not
normally be used by higher-level code.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
# 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
[ also add line to .hgignore - iwj ]
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
When option '-t' is used to do tidy remove, routine xs_directory()
will be called in order to check there are brother directories or not.
The returned pointer should be passed to free() after this check.
Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com>
Add long option '--flat' correspond to short option '-f',
and let it just can be used for subcommand 'ls' (because
in fact it's useless for subcommand 'read' and 'list').
And fix the usage of subcommands 'ls', 'list' and 'chmod'.
Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com>
This is done separately from moving the other utilities into the
mutlicall since ls is slightly different and was already separate.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Presently it's not clear what the allowable character set is for
values in xenstore. The current command-line tools just pass values
to printf("%s",...) so implicitly assume that it's 7-bit printable
ASCII (since the interpretation of 8-bit characters would be unclear).
However there are rumours of programs which dump binary data into
xenstore and/or bugs involving nul bytes being added to the ends of
xenstore values (and even of some drivers insisting on a spurious
nul).
There isn't all that much useful documentation about xenstore. There
is a doc detailing which xenstore keys may be used and what their
meanings are (interface.tex) but it is very out of date, amongst other
reasons because it's in format which is not very easy to update when
adding functionality to the code and because there is no way to check
programs' behaviour in xenstore against the spec. I think the
xenstore part of interface.tex should be replaced with a new document
in a simpler format, which should amonst other things be sufficiently
machine-readable that automatic testing could reveal at least basic
out-of-spec behaviours like setting or using undocumented keys.
This new document ought to specify the allowable character set of both
keys and values, and ought to specify the xenstored protocol as well.
It seems to me that the appropriate character set for xenstore values
is 7-bit printing ASCII (0x20..0x7e). Values should not have a
trailing nul byte `on the wire' but of course the xs library interface
should continue to add an additional nul beyond the quoted length for
the convenience of callers.
That is consistent with nearly all of the existing uses and makes the
whole system much more tractable compared to an explicit expectation
that binary data will be stored. (For example, if we like binary data
in xenstore, why are uuids represented in their printable hex
encoding?) xenstore data is supposedly non-performance-critical
metadata for use by control plane machinery so the overhead of
printing and parsing text strings is hardly a problem.
Applications which set binary values should be deprecated but to avoid
breaking those applications xenstored should continue indefinitely to
be binary-transparent.
Under these circumstances it can only be regarded as a bug that the
current command-line tools are lossy in the presence of binary data.
Not only does this make them break for those now-deprecated uses, but
it also prevents them from being used to detect and debug problems
relating to the exact byte strings being recorded in xenstore.
As a first step towards the utopia I describe above, this patch
causes xenstore-read and -ls to \-escape the values of xenstore
keys, and xenstore-write to un-\-escape them. The escaping is a
subset of that permitted by C89; only \t \r \n \\ and hex and octal
are used and recognised. (So no \f, \a etc.)
This change will not change the representation by these tools of
values which contain only 7-bit printing ASCII characters unless they
contain \'s.
Values which contain \'s will need to be quoted on entry and dequoted
on exit if being manipulated by xenstore-*. The only values likely to
be affected are paths in Windows guest filesystems and in practice we
believe that any such filename which is actually relevant to anything
will be set other than via xenstore-write.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
This utility permits developers and administrators to
manually change the permissions on arbitrary locations in XenStore
from the command line. This is often helpful if you're trying to debug an
application that relies on XenStore and is encountering difficulties
with permissions.
Signed-off-by: Michael LeMay <mdlemay@epoch.ncsc.mil>
Redirect all output to a buffer and only print the buffer once the
transaction succeeds, discarding output from previous attempts.
In particular, fixes failures when the (block) backend driver would
not configure because reads from the hotplug script did get double
output when a transaction had to be redone.
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
work if the transaction caused a retry, because optind had been obliterated.
Achieve this by splitting the main body of the loop off to a separate function,
meaning that we get rid of the goto out at the same time.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
connection, plus interleaving of transactional and
non-transactional accesses. A transaction identifier is added
to the xsd_sockmsg header structure (0 means 'not in context
of a transaction'). The user and kernel xs interfaces accept
a pointer to a transaction handle where appropriate --
currently this is directly cast to an integer identifier in
the client library / kernel driver, but will allow for keeping
extra dynamic client-side state in future if we need to.
The transaction mutex has now gone. It's replaced with a
read-write mutex, but this is only acquired for exclusive
access during suspend/resume, to ensure there are no in-progress
transactions.
Signed-off-by: Keir Fraser <keir@xensource.com>
handle on appropriate operations. Next step is to plug this
through to the store daemon and get rid of the nasty serialisation
mutex for transactions.
Signed-off-by: Keir Fraser <keir@xensource.com>
Make xenstored use tdb, transactions can soft-fail (EAGAIN)
Transactions no longer take root dir, no longer lock & block: commit can fail spuriously with EAGAIN, not ETIMEDOUT.
Speeds up transactions by over 1000 times, should be NFS safe.
New program: xs_tdb_dump to dump raw TDB contents.
Don't do failure testing: we are no longer robust against all ENOMEM 8(
Introduce "struct node" which contains perms, children and data.
Make struct xs_permissions unpadded, so we can write to tdb w/o valgrind complaints.
Gently modify TDB to use talloc, not do alloc on tdb_delete.
Fix up transaction users for new semantics.
Don't need a transaction around a single read in xen/i386/kernel/smpboot.c.
Python: transaction_start() returns True/False rather than raising exception on EAGAIN.
Fix usage comment on xs_transaction_end().
Include stdarg to xs_tdb_dump so it compiles.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Also add simple read/write/rm clients for command line access to the
store (using the xenbus_dev store connection).
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
Simon Gaiser
Andrew Cooper
Ian Jackson
Chunyan Liu
Ian Campbell
Keir Fraser
Christian Limpach
kfraser@localhost.localdomain
vhanquez@kneesa.uk.xensource.com
kaf24@firebug.cl.cam.ac.uk
cl349@firebug.cl.cam.ac.uk
emellor@leeni.uk.xensource.com
emellor@ewan