[Pkg-xen-devel] Ill-advised use of xs_open flag 1UL<<2 by Debian

[Ian Jackson]

Hi.  Thanks for taking the time to help.

Bastian Blank writes ("Re: [Pkg-xen-devel] Ill-advised use of xs_open flag 1UL<<2 by Debian"):
> On Tue, Oct 09, 2018 at 04:04:24PM +0100, Ian Jackson wrote:
> >   The Debian Xen packages have had a very bad patch which I propose to
> >   simply drop, with minor compatibility implications, unless someone
> >   can explain what it is for and why it is still needed, and/or has a
> >   better plan.
> 
> It is still needed, as the underlying change (done by you) constitutes
> an ABI change of the library.
...
> commit d310383831923070727745af97776dcb6078e4f7
> Author: Ian Jackson <Ian.Jackson at eu.citrix.com>
> Date:   Tue Dec 14 16:56:54 2010 +0000

I looked at that change and I think I see a glimmer of an ABI problem:
That change introduces a new XS_OPEN_SOCKETONLY flag which is ignored
by old libraries, and changes the tools to use it.

So if the xenstore tools are upgraded first, they will call xs_open
with XS_OPEN_SOCKETONLY (rather than, previously xs_daemon_open), but
XS_OPEN_SOCKETONLY would be ignored and the problem for which it was
invented would occur.

I think this means we should have bumped the library (or symbol) minor
version and thereby caused a dependency to ensure that the library
would be upgraded first.

However, I don't think this can be the whole picture because I don't
see how the XS_OPEN_DOMAINONLY flag would avoid this problem.  Or,
indeed, any ABI problem.  It is passed, and understood, only by new
utilities and libraries.

But that was all a long time ago.  There is no longer any need to make
upgrades from squeeze or whatever work correctly.


If this functionality (XS_OPEN_DOMAINONLY) is still needed then we
need to properly allocate it a new flag bit which won't clash with
upstream.

But I'm not convinced it is needed.  As I say, I reverted this patch
and the resulting setup works fine.  I tested it with new binaries,
without XS_OPEN_DOMAINONLY, and also a new library which doesn't
honour 1<<2 that way, but I don't see how there would be a difficulty
with upgrade skew either.


Thanks,
Ian.