[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] xenstore tools -s option behaviour



Hi,

I was investigating the behaviour of the -s option and I'm not sure if the 
behaviour of xs_open() is exactly as 
intended.  In my case I am running xenstored in the dom0.  Running a strace on 
xenstore-read with/without the -s 
option shows the tool always using xenstore socket.  The flag which the -s 
option toggles suggests that it is 
supposed to force use of the socket over the xenbus device when both are 
available.

socket is 0 by default, -s sets socket = 1

xsh = xs_open(socket ? XS_OPEN_SOCKETONLY : 0);

struct xs_handle *xs_open(unsigned long flags)
{
        struct xs_handle *xsh = NULL;

        if (flags & XS_OPEN_READONLY)
                xsh = get_handle(xs_daemon_socket_ro());
        else
                xsh = get_handle(xs_daemon_socket());
        /* regardles of the state of XS_OPEN_SOCKET_ONLY xsh
        will be set when the socket is available */

        if (!xsh && !(flags & XS_OPEN_SOCKETONLY))
                xsh = get_handle(xs_domain_dev());

        if (xsh && (flags & XS_UNWATCH_FILTER))
                xsh->unwatch_filter = true;

        return xsh;
}

Should the correct behaviour be to use xs_domain_dev() when XS_OPEN_SOCKET_ONLY 
is not set and only use 
xs_daemon_socket() when it is?  The conditions are slightly complicated by the 
availability of 
xs_daemon_socket_ro().  I am working with this version of xs_open() where we 
want to prefer the device unless -s 
is used.

struct xs_handle *xs_open(unsigned long flags)
{
        struct xs_handle *xsh = NULL;

        if (flags & XS_OPEN_READONLY) {
                xsh = get_handle(xs_daemon_socket_ro());
        } else if (flags & XS_OPEN_SOCKETONLY) {
                xsh = get_handle(xs_daemon_socket());
        } else {
                xsh = get_handle(xs_domain_dev());
        }

        if (xsh && (flags & XS_UNWATCH_FILTER))
                xsh->unwatch_filter = true;

        return xsh;
}


I did the original analysis in 4.4 but the 4.6 code seems to be the same.

Thanks,
James

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.