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?