[Pkg-xen-devel] xenstore situation

[Ian Campbell]

On Sun, 2011-05-01 at 14:05 +0200, Bastian Blank wrote:
> Hi folks
> 
> Some time ago I split out the xenstore utils out of the main utils
> package. I thought myself what could possibly be wrong and found
> nothing. I was wrong.

It never occurred to me before that people might think xenstored wasn't
covered by the same "matched set" rule that normally applies the
toolstack and hypervisor, although thinking about it now I can see why
you might have thought so since the xenstored code base has been pretty
much static for a long time.

> Xen upstream decided to break the protocol between the client library
> and the daemon in a subtle way. This was compensated with a change in
> the daemon.

The default communication channel which tools running in the same domain
as xenstored use to talk to xenstored was changed and this exposed a
_bug_ in the daemon whereby relative paths were relative to / over one
channel and /local/domain/$DOMID over the other. A xenstore connection
which does not evaluate relative paths versus /local/domain/$DOMID is
pretty useless for many clients and having this behaviour differ
depending on the connection method used was simply a bug so we fixed it.
(FWIW the ocaml xenstored did not have this bug and always had the same
behaviour as the C xenstored does in 4.1)

Even though we don't really support it, it still a shame that this broke
newer libxenstore talking to older xenstored, and with the benefit of
hindsight we could probably have handled the transition better (or at
least bumped the SONAME). IMHO the "fix" at this point would be to
backport the bugfix to the 4.0 version of xenstored.

> Earlier versions of the library used the kernel access method as
> default. There is support to make relative paths absolute and the daemon
> always have absolute paths. This default was changed.

Specifically older versions of the library required callers to
explicitly ask for a kernel or socket based connection (a choice that
apps are not generally able to make in a sensible way) and the new
interface hides this decision from the calling application and tries
socket first and then kernel, usually this leads to using the socket
interface in domain 0 but it is also seemlessly compatible with running
xenstored in another domain without requiring fallback code be added to
every libxenstore user.

> The current version defaults to using socket access. Because the daemon
> now may get relative paths, it changed to make it absolute on its
> own[1]. This means that a current libxenstore is not compatible with
> older xenstored.
> 
> Bastian
> 
> [1]: Changeset f1b435507f34

-- 
Ian Campbell

I am currently transitioning to a new OpenPGP key, please see:
http://www.hellion.org.uk/key-transition-2011-04-27-2F6BCD59-to-79074FA8.txt

I like the way ONLY their mouths move ...  They look like DYING OYSTERS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20110502/5f875675/attachment.pgp>