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

Re: [Xen-devel] [PATCH 0/3] Introduce xensock socket and implement sockback and sockfront drivers

On Fri, 2014-08-08 at 15:41 +0100, Stefano Stabellini wrote:
> On Fri, 8 Aug 2014, David Vrabel wrote:
> > On 08/08/14 12:32, Oleksandr Dmytryshyn wrote:
> > > Next series of the patches adds new socket support: xensock.
> > > Those sockets will be used for the xen-sock frontend/backend
> > > drivers. Those drivers will allow to connect via xensock
> > > sockets (in this case dom0/domD sockets can be used for the
> > > server application and domU sockets can be used for the
> > > client application). Those sockets are similar to the TCP sockets.
> > > But there are some limitations. Xensock sockets
> > > ignore an address and can act only as the stream
> > > sockets. Only one xensock socket can be opened in the frontend
> > > side and it will be connected with the single xensock socket
> > > in the backend side (this link is created automatically by
> > > frontend and backend driver).
> > 
> > You should look at using AF_VSOCK sockets instead.
> Even if he uses AF_VSOCK instead of introducing AF_XENSOCK, he would
> still need to add a new Xen specific frontend and backend pair, right?
> I am in favor of this work, but you would need to spend a few words in
> the patch description to explain why libvchan doesn't fit your needs.


It would be nice (tm) to have an in kernel implementation of the vchan
code so that a userprocess in one domain and kernel code in another
could interact over vchan (I can't remember who but someone needed
something like that), but I guess this is somewhat orthogonal to this


Xen-devel mailing list



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