Re: [Xen-devel] [PATCH v4 11/16] tools: add simple vchan-socket-proxy

2020-01-21 Thread Marek Marczykowski-Górecki 
On Tue, Jan 21, 2020 at 02:43:03PM -0500, Jason Andryuk wrote:
> On Tue, Jan 14, 2020 at 9:42 PM Marek Marczykowski-Górecki
>  wrote:
> >
> > Add a simple proxy for tunneling socket connection over vchan. This is
> > based on existing vchan-node* applications, but extended with socket
> > support. vchan-socket-proxy serves both as a client and as a server,
> > depending on parameters. It can be used to transparently communicate
> > with an application in another domian that normally expose UNIX socket
> > interface. Specifically, it's written to communicate with qemu running
> > within stubdom.
> >
> > Server mode listens for vchan connections and when one is opened,
> > connects to a pointed UNIX socket.  Client mode listens on UNIX
> > socket and when someone connects, opens a vchan connection.  Only
> > a single connection at a time is supported.
> >
> > Additionally, socket can be provided as a number - in which case it's
> > interpreted as already open FD (in case of UNIX listening socket -
> > listen() needs to be already called). Or "-" meaning stdin/stdout - in
> > which case it is reduced to vchan-node2 functionality.
> >
> > Example usage:
> >
> > 1. (in dom0) vchan-socket-proxy --mode=client 
> > /local/domain//data/vchan/1234 /run/qemu.(DOMID)
> >
> > 2. (in DOMID) vchan-socket-proxy --mode=server 0
> >/local/domain//data/vchan/1234 /run/qemu.(DOMID)
> >
> > This will listen on /run/qemu.(DOMID) in dom0 and whenever connection is
> > made, it will connect to DOMID, where server process will connect to
> > /run/qemu.(DOMID) there. When client disconnects, vchan connection is
> > terminated and server vchan-socket-proxy process also disconnects from
> > qemu.
> >
> > Signed-off-by: Marek Marczykowski-Górecki 
> > ---
> 
> Looks good.  A few typos and string updates below.

Thanks, adjusted.

> Reviewed-by: Jason Andryuk 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 11/16] tools: add simple vchan-socket-proxy

2020-01-21 Thread Jason Andryuk 
On Tue, Jan 14, 2020 at 9:42 PM Marek Marczykowski-Górecki
 wrote:
>
> Add a simple proxy for tunneling socket connection over vchan. This is
> based on existing vchan-node* applications, but extended with socket
> support. vchan-socket-proxy serves both as a client and as a server,
> depending on parameters. It can be used to transparently communicate
> with an application in another domian that normally expose UNIX socket
> interface. Specifically, it's written to communicate with qemu running
> within stubdom.
>
> Server mode listens for vchan connections and when one is opened,
> connects to a pointed UNIX socket.  Client mode listens on UNIX
> socket and when someone connects, opens a vchan connection.  Only
> a single connection at a time is supported.
>
> Additionally, socket can be provided as a number - in which case it's
> interpreted as already open FD (in case of UNIX listening socket -
> listen() needs to be already called). Or "-" meaning stdin/stdout - in
> which case it is reduced to vchan-node2 functionality.
>
> Example usage:
>
> 1. (in dom0) vchan-socket-proxy --mode=client 
> /local/domain//data/vchan/1234 /run/qemu.(DOMID)
>
> 2. (in DOMID) vchan-socket-proxy --mode=server 0
>/local/domain//data/vchan/1234 /run/qemu.(DOMID)
>
> This will listen on /run/qemu.(DOMID) in dom0 and whenever connection is
> made, it will connect to DOMID, where server process will connect to
> /run/qemu.(DOMID) there. When client disconnects, vchan connection is
> terminated and server vchan-socket-proxy process also disconnects from
> qemu.
>
> Signed-off-by: Marek Marczykowski-Górecki 
> ---

Looks good.  A few typos and string updates below.

Reviewed-by: Jason Andryuk 



> diff --git a/tools/libvchan/vchan-socket-proxy.c 
> b/tools/libvchan/vchan-socket-proxy.c
> new file mode 100644
> index 000..6b4ae09
> --- /dev/null
> +++ b/tools/libvchan/vchan-socket-proxy.c



> +static void usage(char** argv)
> +{
> +fprintf(stderr, "usage:\n"
> +"\t%s [options] domainid nodepath [socket-path|file-no|-]\n"
> +"\n"
> +"options:\n"
> +"\t-m, --mode=client|server - vchan connection mode\n"

Add "(client by default)"?

> +"\t-m, --state-path=path - xenstore path where write \"running\" to 
> at startup\n"

-s is the short option here.

> +"\t-v, --verbose - verbose logging\n"
> +"\n"
> +"client: client of a vchan connection, fourth parameter can be:\n"
> +"\tsocket-path: listen on a UNIX socket at this path and connect to 
> vchan\n"
> +"\t  whenever new connection is accepted;\n"
> +"\t  handle multiple _subsequent_ connections, until terminated\n"
> +"\tfile-no: except open FD of a socket in listen mode; otherwise 
> similar to socket-path\n"

Many of these lines are long and hard to read on 80 column terminals.

> +"\t-: open vchan connection immediately and pass the data from 
> stdin/stdout;\n"
> +"\t  terminate when vchan connection is closed\n"
> +"server: server of a vchan connection, fourth parameter can be:\n"
> +"\tsocket-path: connect to this UNIX socket when new vchan 
> connection is accepted\n"
> +"\t  handle multiple _subsequent_ connections, until terminated\n"
> +"\tfile-no: pass data to/from this FD; terminate when vchan 
> connection is closed\n"
> +"\t-: pass data to/from stdin/stdout; terminatate when vchan 
> connection is closed\n",

s/terminatate/terminate/

> +argv[0]);
> +exit(1);
> +}
> +
> +#define BUFSIZE 8192
> +char inbuf[BUFSIZE];
> +char outbuf[BUFSIZE];
> +int insiz = 0;
> +int outsiz = 0;
> +int verbose = 0;
> +
> +static void vchan_wr(struct libxenvchan *ctrl) {
> +int ret;
> +
> +if (!insiz)
> +return;
> +ret = libxenvchan_write(ctrl, inbuf, insiz);
> +if (ret < 0) {
> +fprintf(stderr, "vchan write failed\n");
> +exit(1);
> +}
> +if (verbose)
> +fprintf(stderr, "written %d bytes to vchan\n", ret);

s/written/wrote/

> +if (ret > 0) {
> +insiz -= ret;
> +memmove(inbuf, inbuf + ret, insiz);
> +}
> +}
> +



> +
> +int data_loop(struct libxenvchan *ctrl, int input_fd, int output_fd)
> +{
> +int ret;
> +int libxenvchan_fd;
> +int max_fd;
> +
> +libxenvchan_fd = libxenvchan_fd_for_select(ctrl);
> +for (;;) {
> +fd_set rfds;
> +fd_set wfds;
> +FD_ZERO();
> +FD_ZERO();
> +
> +max_fd = -1;
> +if (input_fd != -1 && insiz != BUFSIZE) {
> +FD_SET(input_fd, );
> +if (input_fd > max_fd)
> +max_fd = input_fd;
> +}
> +if (output_fd != -1 && outsiz) {
> +FD_SET(output_fd, );
> +if (output_fd > max_fd)
> +max_fd = output_fd;
> +}
> +FD_SET(libxenvchan_fd, );
> +if (libxenvchan_fd > max_fd)
> +max_fd = libxenvchan_fd;
> +ret =

Re: [Xen-devel] [PATCH v4 11/16] tools: add simple vchan-socket-proxy

2020-01-17 Thread Marek Marczykowski-Górecki 
On Fri, Jan 17, 2020 at 01:44:20PM -0500, Rich Persaud wrote:
> On Jan 14, 2020, at 21:42, Marek Marczykowski-Górecki 
>  wrote:
> > @@ -66,6 +70,7 @@ install: all
> >$(INSTALL_PROG) libxenvchan.so.$(MAJOR).$(MINOR) $(DESTDIR)$(libdir)
> >ln -sf libxenvchan.so.$(MAJOR).$(MINOR) 
> > $(DESTDIR)$(libdir)/libxenvchan.so.$(MAJOR)
> >ln -sf libxenvchan.so.$(MAJOR) $(DESTDIR)$(libdir)/libxenvchan.so
> > +$(INSTALL_PROG) vchan-socket-proxy $(DESTDIR)$(bindir)
> 
> Does this need directory creation, to avoid vchan binary being named "bin"?
> +   $(INSTALL_DIR) $(DESTDIR)$(bindir)

I guess it depends on makefile execution order. I'll add it to be on the
safe side.

> > +int main(int argc, char **argv)
> > +{
> > +int is_server = 0;
> > +int socket_fd;
> 
> When compiled for OpenEmbedded / OpenXT, gcc complained about socket_fd being 
> uninitialized before possible use.

I think gcc is wrong here - in all the paths socket_fd is used, it is
initialized under the same conditions (socket_path != "-" and
!is_server). But I'll add initializer to mute this warning.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 11/16] tools: add simple vchan-socket-proxy

2020-01-17 Thread Rich Persaud 
On Jan 14, 2020, at 21:42, Marek Marczykowski-Górecki 
 wrote:
> 
> diff --git a/tools/libvchan/Makefile b/tools/libvchan/Makefile
> index 7892750..1c845ca 100644
> --- a/tools/libvchan/Makefile
> +++ b/tools/libvchan/Makefile
> @@ -13,6 +13,7 @@ LIBVCHAN_PIC_OBJS = $(patsubst %.o,%.opic,$(LIBVCHAN_OBJS))
> LIBVCHAN_LIBS = $(LDLIBS_libxenstore) $(LDLIBS_libxengnttab) 
> $(LDLIBS_libxenevtchn)
> $(LIBVCHAN_OBJS) $(LIBVCHAN_PIC_OBJS): CFLAGS += $(CFLAGS_libxenstore) 
> $(CFLAGS_libxengnttab) $(CFLAGS_libxenevtchn)
> $(NODE_OBJS) $(NODE2_OBJS): CFLAGS += $(CFLAGS_libxengnttab) 
> $(CFLAGS_libxenevtchn)
> +vchan-socket-proxy.o: CFLAGS += $(CFLAGS_libxenstore) $(CFLAGS_libxenctrl) 
> $(CFLAGS_libxengnttab) $(CFLAGS_libxenevtchn)
> 
> MAJOR = 4.14
> MINOR = 0
> @@ -39,7 +40,7 @@ $(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR)
> $(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude)
> 
> .PHONY: all
> -all: libxenvchan.so vchan-node1 vchan-node2 libxenvchan.a $(PKG_CONFIG_INST) 
> $(PKG_CONFIG_LOCAL)
> +all: libxenvchan.so vchan-node1 vchan-node2 vchan-socket-proxy libxenvchan.a 
> $(PKG_CONFIG_INST) $(PKG_CONFIG_LOCAL)
> 
> libxenvchan.so: libxenvchan.so.$(MAJOR)
>ln -sf $< $@
> @@ -59,6 +60,9 @@ vchan-node1: $(NODE_OBJS) libxenvchan.so
> vchan-node2: $(NODE2_OBJS) libxenvchan.so
>$(CC) $(LDFLAGS) -o $@ $(NODE2_OBJS) $(LDLIBS_libxenvchan) 
> $(APPEND_LDFLAGS)
> 
> +vchan-socket-proxy: vchan-socket-proxy.o libxenvchan.so
> +$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenvchan) $(LDLIBS_libxenstore) 
> $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
> +
> .PHONY: install
> install: all
>$(INSTALL_DIR) $(DESTDIR)$(libdir)
> @@ -66,6 +70,7 @@ install: all
>$(INSTALL_PROG) libxenvchan.so.$(MAJOR).$(MINOR) $(DESTDIR)$(libdir)
>ln -sf libxenvchan.so.$(MAJOR).$(MINOR) 
> $(DESTDIR)$(libdir)/libxenvchan.so.$(MAJOR)
>ln -sf libxenvchan.so.$(MAJOR) $(DESTDIR)$(libdir)/libxenvchan.so
> +$(INSTALL_PROG) vchan-socket-proxy $(DESTDIR)$(bindir)

Does this need directory creation, to avoid vchan binary being named "bin"?
+   $(INSTALL_DIR) $(DESTDIR)$(bindir)


> diff --git a/tools/libvchan/vchan-socket-proxy.c 
> b/tools/libvchan/vchan-socket-proxy.c
> new file mode 100644
> index 000..6b4ae09
> --- /dev/null
> +++ b/tools/libvchan/vchan-socket-proxy.c
> @@ -0,0 +1,469 @@
> +/**
> + * @file
> + * @section AUTHORS
> + *
> + * Copyright (C) 2010  Rafal Wojtczuk  
> + *
> + *  Authors:
> + *   Rafal Wojtczuk  
> + *   Daniel De Graaf 
> + *   Marek Marczykowski-Górecki  
> + *
> + * @section LICENSE
> + *
> + *  This program is free software; you can redistribute it and/or
> + *  modify it under the terms of the GNU Lesser General Public
> + *  License as published by the Free Software Foundation; either
> + *  version 2.1 of the License, or (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + *  Lesser General Public License for more details.
> + *
> + *  You should have received a copy of the GNU Lesser General Public
> + *  License along with this program; If not, see 
> .
> + *
> + * @section DESCRIPTION
> + *
> + * This is a vchan to unix socket proxy. Vchan server is set, and on client
> + * connection, local socket connection is established. Communication is 
> bidirectional.
> + * One client is served at a time, clients needs to coordinate this 
> themselves.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +static void usage(char** argv)
> +{
> +fprintf(stderr, "usage:\n"
> +"\t%s [options] domainid nodepath [socket-path|file-no|-]\n"
> +"\n"
> +"options:\n"
> +"\t-m, --mode=client|server - vchan connection mode\n"
> +"\t-m, --state-path=path - xenstore path where write \"running\" to 
> at startup\n"
> +"\t-v, --verbose - verbose logging\n"
> +"\n"
> +"client: client of a vchan connection, fourth parameter can be:\n"
> +"\tsocket-path: listen on a UNIX socket at this path and connect to 
> vchan\n"
> +"\t  whenever new connection is accepted;\n"
> +"\t  handle multiple _subsequent_ connections, until terminated\n"
> +"\tfile-no: except open FD of a socket in listen mode; otherwise 
> similar to socket-path\n"
> +"\t-: open vchan connection immediately and pass the data from 
> stdin/stdout;\n"
> +"\t  terminate when vchan connection is closed\n"
> +"server: server of a vchan connection, fourth parameter can be:\n"
> +"\tsocket-path: connect to this UNIX socket when new vchan 
> connection is accepted\n"
> +"\t  handle multiple _subsequent_ connections, until terminated\n"

Re: [Xen-devel] [PATCH v4 11/16] tools: add simple vchan-socket-proxy

2020-01-17 Thread Jan Beulich 
On 16.01.2020 18:11, Marek Marczykowski-Górecki  wrote:
> On Wed, Jan 15, 2020 at 12:02:42PM +0100, Jan Beulich wrote:
>> On 15.01.2020 03:39, Marek Marczykowski-Górecki wrote:
>>>  .gitignore  |   1 +-
>>
>> I guess this is why various non-tool-stack maintainers have
>> been Cc-ed. It would have been nice if you had stripped the
>> unnecessary Cc-s. I don't think ./MAINTAINERS can properly
>> express a suitable rule of Cc REST if the adjustment is not
>> simply accompanying the addition of some new output file.
> 
> Maybe a solution would be to make use of more .gitignore files in
> specific subdirs? I see there are some, but for example tools/misc is
> mentioned in _both_ toplevel .gitignore and tools/misc/.gitignore.

Well, yes, we've been discussing this elsewhere. We should settle
on one model (central vs per-main-subtree vs per-dir), I think. I
have no particular preference except for disliking any mixed models.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 11/16] tools: add simple vchan-socket-proxy

2020-01-16 Thread Marek Marczykowski-Górecki 
On Wed, Jan 15, 2020 at 12:02:42PM +0100, Jan Beulich wrote:
> On 15.01.2020 03:39, Marek Marczykowski-Górecki wrote:
> >  .gitignore  |   1 +-
> 
> I guess this is why various non-tool-stack maintainers have
> been Cc-ed. It would have been nice if you had stripped the
> unnecessary Cc-s. I don't think ./MAINTAINERS can properly
> express a suitable rule of Cc REST if the adjustment is not
> simply accompanying the addition of some new output file.

Maybe a solution would be to make use of more .gitignore files in
specific subdirs? I see there are some, but for example tools/misc is
mentioned in _both_ toplevel .gitignore and tools/misc/.gitignore.

> >  tools/libvchan/Makefile |   7 +-
> >  tools/libvchan/init.c.rej   |  60 -
> 
> Now since I've been Cc-ed, I'd like to ask what this is about.

This is obviously a mistake. Will remove in the next revision.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 11/16] tools: add simple vchan-socket-proxy

2020-01-15 Thread Jan Beulich 
On 15.01.2020 03:39, Marek Marczykowski-Górecki wrote:
> Add a simple proxy for tunneling socket connection over vchan. This is
> based on existing vchan-node* applications, but extended with socket
> support. vchan-socket-proxy serves both as a client and as a server,
> depending on parameters. It can be used to transparently communicate
> with an application in another domian that normally expose UNIX socket
> interface. Specifically, it's written to communicate with qemu running
> within stubdom.
> 
> Server mode listens for vchan connections and when one is opened,
> connects to a pointed UNIX socket.  Client mode listens on UNIX
> socket and when someone connects, opens a vchan connection.  Only
> a single connection at a time is supported.
> 
> Additionally, socket can be provided as a number - in which case it's
> interpreted as already open FD (in case of UNIX listening socket -
> listen() needs to be already called). Or "-" meaning stdin/stdout - in
> which case it is reduced to vchan-node2 functionality.
> 
> Example usage:
> 
> 1. (in dom0) vchan-socket-proxy --mode=client 
> /local/domain//data/vchan/1234 /run/qemu.(DOMID)
> 
> 2. (in DOMID) vchan-socket-proxy --mode=server 0
>/local/domain//data/vchan/1234 /run/qemu.(DOMID)
> 
> This will listen on /run/qemu.(DOMID) in dom0 and whenever connection is
> made, it will connect to DOMID, where server process will connect to
> /run/qemu.(DOMID) there. When client disconnects, vchan connection is
> terminated and server vchan-socket-proxy process also disconnects from
> qemu.
> 
> Signed-off-by: Marek Marczykowski-Górecki 
> ---
>  .gitignore  |   1 +-

I guess this is why various non-tool-stack maintainers have
been Cc-ed. It would have been nice if you had stripped the
unnecessary Cc-s. I don't think ./MAINTAINERS can properly
express a suitable rule of Cc REST if the adjustment is not
simply accompanying the addition of some new output file.

>  tools/libvchan/Makefile |   7 +-
>  tools/libvchan/init.c.rej   |  60 -

Now since I've been Cc-ed, I'd like to ask what this is about.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v4 11/16] tools: add simple vchan-socket-proxy

2020-01-14 Thread Marek Marczykowski-Górecki 
Add a simple proxy for tunneling socket connection over vchan. This is
based on existing vchan-node* applications, but extended with socket
support. vchan-socket-proxy serves both as a client and as a server,
depending on parameters. It can be used to transparently communicate
with an application in another domian that normally expose UNIX socket
interface. Specifically, it's written to communicate with qemu running
within stubdom.

Server mode listens for vchan connections and when one is opened,
connects to a pointed UNIX socket.  Client mode listens on UNIX
socket and when someone connects, opens a vchan connection.  Only
a single connection at a time is supported.

Additionally, socket can be provided as a number - in which case it's
interpreted as already open FD (in case of UNIX listening socket -
listen() needs to be already called). Or "-" meaning stdin/stdout - in
which case it is reduced to vchan-node2 functionality.

Example usage:

1. (in dom0) vchan-socket-proxy --mode=client 
/local/domain//data/vchan/1234 /run/qemu.(DOMID)

2. (in DOMID) vchan-socket-proxy --mode=server 0
   /local/domain//data/vchan/1234 /run/qemu.(DOMID)

This will listen on /run/qemu.(DOMID) in dom0 and whenever connection is
made, it will connect to DOMID, where server process will connect to
/run/qemu.(DOMID) there. When client disconnects, vchan connection is
terminated and server vchan-socket-proxy process also disconnects from
qemu.

Signed-off-by: Marek Marczykowski-Górecki 
---
 .gitignore  |   1 +-
 tools/libvchan/Makefile |   7 +-
 tools/libvchan/init.c.rej   |  60 -
 tools/libvchan/vchan-socket-proxy.c | 469 +-
 4 files changed, 536 insertions(+), 1 deletion(-)
 create mode 100644 tools/libvchan/init.c.rej
 create mode 100644 tools/libvchan/vchan-socket-proxy.c

diff --git a/.gitignore b/.gitignore
index 017856c..1c9dd93 100644
--- a/.gitignore
+++ b/.gitignore
@@ -372,6 +372,7 @@ tools/misc/xenwatchdogd
 tools/misc/xen-hvmcrash
 tools/misc/xen-lowmemd
 tools/libvchan/vchan-node[12]
+tools/libvchan/vchan-socket-proxy
 tools/ocaml/*/.ocamldep.make
 tools/ocaml/*/*.cm[ixao]
 tools/ocaml/*/*.cmxa
diff --git a/tools/libvchan/Makefile b/tools/libvchan/Makefile
index 7892750..1c845ca 100644
--- a/tools/libvchan/Makefile
+++ b/tools/libvchan/Makefile
@@ -13,6 +13,7 @@ LIBVCHAN_PIC_OBJS = $(patsubst %.o,%.opic,$(LIBVCHAN_OBJS))
 LIBVCHAN_LIBS = $(LDLIBS_libxenstore) $(LDLIBS_libxengnttab) 
$(LDLIBS_libxenevtchn)
 $(LIBVCHAN_OBJS) $(LIBVCHAN_PIC_OBJS): CFLAGS += $(CFLAGS_libxenstore) 
$(CFLAGS_libxengnttab) $(CFLAGS_libxenevtchn)
 $(NODE_OBJS) $(NODE2_OBJS): CFLAGS += $(CFLAGS_libxengnttab) 
$(CFLAGS_libxenevtchn)
+vchan-socket-proxy.o: CFLAGS += $(CFLAGS_libxenstore) $(CFLAGS_libxenctrl) 
$(CFLAGS_libxengnttab) $(CFLAGS_libxenevtchn)
 
 MAJOR = 4.14
 MINOR = 0
@@ -39,7 +40,7 @@ $(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR)
 $(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude)
 
 .PHONY: all
-all: libxenvchan.so vchan-node1 vchan-node2 libxenvchan.a $(PKG_CONFIG_INST) 
$(PKG_CONFIG_LOCAL)
+all: libxenvchan.so vchan-node1 vchan-node2 vchan-socket-proxy libxenvchan.a 
$(PKG_CONFIG_INST) $(PKG_CONFIG_LOCAL)
 
 libxenvchan.so: libxenvchan.so.$(MAJOR)
ln -sf $< $@
@@ -59,6 +60,9 @@ vchan-node1: $(NODE_OBJS) libxenvchan.so
 vchan-node2: $(NODE2_OBJS) libxenvchan.so
$(CC) $(LDFLAGS) -o $@ $(NODE2_OBJS) $(LDLIBS_libxenvchan) 
$(APPEND_LDFLAGS)
 
+vchan-socket-proxy: vchan-socket-proxy.o libxenvchan.so
+   $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenvchan) $(LDLIBS_libxenstore) 
$(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 .PHONY: install
 install: all
$(INSTALL_DIR) $(DESTDIR)$(libdir)
@@ -66,6 +70,7 @@ install: all
$(INSTALL_PROG) libxenvchan.so.$(MAJOR).$(MINOR) $(DESTDIR)$(libdir)
ln -sf libxenvchan.so.$(MAJOR).$(MINOR) 
$(DESTDIR)$(libdir)/libxenvchan.so.$(MAJOR)
ln -sf libxenvchan.so.$(MAJOR) $(DESTDIR)$(libdir)/libxenvchan.so
+   $(INSTALL_PROG) vchan-socket-proxy $(DESTDIR)$(bindir)
$(INSTALL_DATA) libxenvchan.h $(DESTDIR)$(includedir)
$(INSTALL_DATA) libxenvchan.a $(DESTDIR)$(libdir)
$(INSTALL_DATA) xenvchan.pc $(DESTDIR)$(PKG_INSTALLDIR)
diff --git a/tools/libvchan/init.c.rej b/tools/libvchan/init.c.rej
new file mode 100644
index 000..8b3ed73
--- /dev/null
+++ b/tools/libvchan/init.c.rej
@@ -0,0 +1,60 @@
+--- tools/libvchan/init.c
 tools/libvchan/init.c
+@@ -266,31 +266,33 @@ static int init_xs_srv(struct libxenvchan *ctrl, int 
domain, const char* xs_base
+   perms[1].id = domain;
+   perms[1].perms = XS_PERM_READ;
+ 
+-retry_transaction:
+-  xs_trans = xs_transaction_start(xs);
+-  if (!xs_trans)
+-  goto fail;
+-
+-  snprintf(ref, sizeof ref, "%d", ring_ref);
+-  snprintf(buf, sizeof buf, "%s/ring-ref", xs_base);
+-  if (!xs_write(xs, xs_trans, buf, ref, strlen(ref)))
+-  goto fail;
+-