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

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

On Mon, 2 Mar 2020 11:24:50 +0900
David Stevens <stevensd@chromium.org> wrote:

> On Fri, Feb 28, 2020 at 7:30 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> > On Fri, Feb 28, 2020 at 07:11:40PM +0900, David Stevens wrote:  
> > > > 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.  
> >
> > As far I know this is exactly what virtio-wayland does today if you try
> > to pass a unix socket file descriptor to the other side, so I assume
> > this functionality is needed ...  
> 
> As Zach said earlier, virtio-wayland implements just enough FD sharing
> support to get wayland working. However, there are many other
> situations where virtio-wayland's unix socket support isn't
> sufficient. I think adding support for sharing unix sockets to a
> generic virtio-ipc would imply that the support is more comprehensive
> than would be feasible to implement. So while virtio-ipc should
> support wayland, either directly or with the support of
> userspace/another virtio device, it also shouldn't overpromise what it
> is capable of doing.

I feel like some of the terms I used were confusing, but I think we're
on the same page when it comes to the actual implementation and
features we want to see supported by this virtio-ipc device. So, how
about rephrasing it this way:

"
virtio-ipc aims at providing a protocol-agnostic message passing
interface with extensible resource-passing capabilities. The initial
implementation should cover the wayland use case, and as such,
should support passing the following type of resources:

* opened virtio-ipc connections (similar to passing an FD to one end of
  a unix pipe, except communication would be bi-directional). With this
  feature we can let user space implement all sort of proxies
  (sockets <-> virtio-ipc, pipes <-> virtio-ipc, ...)
* virtio-gpu dmabufs
* ... [need to look in more details what's needed for keymap and file
  sharing]
"

Note that it's not that far from what virtio-wayland provides today with
2 main differences:

1/ the name of the device no longer implies that the interface is
   wayland-specific
2/ virtio-ipc is resource-type agnostic, and FD <-> resource ID mapping
   creation is left to the subsystem handling the resource. That means
   we shouldn't see this sort of 'convert FD to res-type X' logic [1]
   in the virtio-ipc driver, which should make it easier to extend while
   keeping the code base small enough/sane, no matter how far we
   decide to go with resource passing.

[1]https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/drivers/virtio/virtio_wl.c#786