On Mon, 24 Feb 2020 14:57:43 +0100 Boris Brezillon <[email protected]> wrote:
> On Mon, 24 Feb 2020 14:42:31 +0100 > Gerd Hoffmann <[email protected]> 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). --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
