Re: [virtio-dev] [RFC] Upstreaming virtio-wayland (or an alternative)

[Boris Brezillon <boris.brezillon@collabora.com>]

On Fri, 28 Feb 2020 19:11:40 +0900
David Stevens <stevensd@chromium.org> wrote:

> > > > Yes, sure, we need to exactly specify the different kinds of file
> > > > handles / resources. I think it makes sense to have a virtio feature
> > > > flag for each of them, so guest+host can easily negotiate what they are
> > > > able to handle and what not.  
> > >
> > > I was expecting that to be a feature of the resource producers
> > > (virtio-gpu, virtio-fs, ...) rather than a feature of virtio-ipc
> > > itself.  
> >
> > "resources from other virtio devices" would be one virtio-ipc feature
> > flag.  And, yes, that would for the most part have the other device
> > handle the problem.
> >
> > But there also is "unix socket", or maybe a somewhat broader "stream",
> > which would be another feature flag I guess because virtio-ipc would
> > just tunnel the stream without the help from other devices.  
> 
> Can you elaborate on what you mean by this? I can envision how
> virtio-ipc would be a generic mechanism for passing data+virtio
> resources, including any new types of resources it itself defines.
> However, if "unix sockets" or a generic "stream" expands beyond
> virtio, that seems too broad, with too many edge cases to be feasible
> to implement.

I don't think we need to bridge unix sockets or any kind of stream
interface, like pipes, regular sockets, ... in kernel space. If
virtio-ipc provides a way to create anonymous virtio-ipc connections
whose FDs can be passed to a opened virtio-ipc connection, we can
implement those bridges in user space. fstat() allows us to know what
kind of FD we're receiving from the unix socket (socket, regular
file, fifo), and for sockets, we even have
getsockopt({SO_DOMAIN,SO_TYPE}) to get a more precise information.