[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Re: [RFC] Upstreaming virtio-wayland (or an alternative)
On Mon, 24 Feb 2020 14:57:43 +0100 Boris Brezillon <boris.brezillon@collabora.com> wrote: > On Mon, 24 Feb 2020 14:42:31 +0100 > Gerd Hoffmann <kraxel@redhat.com> wrote: > > > Hi, > > > > > > But let's say we go for a dedicated virtio-device to preserve this > > > > granularity. Should we aim at providing a generic virtio-msg device or > > > > should we keep this so-called wayland-specific virtio device (I'd like > > > > to remind you that it's actually protocol-agnostic)? > > > > > > Maybe there's another option (not sure I mentioned it previously): > > > de-correlate the message passing and fd-passing interfaces. If we add a > > > virtio-fd device that takes care of FD passing between guest and host, > > > we can still use a regular vsock to pass messages (can be vhost or > > > !vhost depending on your level of paranoÃa). The wayland proxies would > > > then queue/dequeue messages to/from the vsock and FDs to/from virtio-fd. > > > > Hmm, I suspect supporting unix socket passing (by creating a tunnel for > > them) is going to be tricky in with that approach. > > Yes, If you want a generic vsock <-> unix proxy, you'll have to > encapsulate the 'message+number of FDs passed' information so the other > end knows how many FDs should be dequeued on the virtio-fd dev. The > other option being to implement proxies that can parse the messages and > extract the 'number of FDs' from there. Nevermind, I misunderstood your concern. Indeed, supporting unix FD passing would be trickier (you'd need to attach both a vosck and a virtio-fd instance).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]