All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: David Stevens <stevensd@chromium.org>
Cc: "Gerd Hoffmann" <kraxel@redhat.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Zach Reizner" <zachr@chromium.org>,
	"Stéphane Marchesin" <marcheu@chromium.org>,
	"Tomeu Vizoso" <tomeu.vizoso@collabora.com>,
	"Tomasz Figa" <tfiga@chromium.org>,
	virtio-dev@lists.oasis-open.org,
	"Alexandros Frantzis" <alexandros.frantzis@collabora.co.uk>
Subject: Re: [virtio-dev] [RFC] Upstreaming virtio-wayland (or an alternative)
Date: Thu, 27 Feb 2020 12:51:08 +0100	[thread overview]
Message-ID: <20200227125108.52873611@collabora.com> (raw)
In-Reply-To: <CAD=HUj5jCSotWP0pN_QMFYwuJMnaW8Xzzz1ZhCkjYXFu94ccoA@mail.gmail.com>

On Thu, 27 Feb 2020 20:14:22 +0900
David Stevens <stevensd@chromium.org> wrote:

> On Thu, Feb 27, 2020 at 6:09 PM Boris Brezillon
> <boris.brezillon@collabora.com> wrote:
> >
> > On Thu, 27 Feb 2020 13:20:51 +0900
> > David Stevens <stevensd@chromium.org> wrote:
> >  
> > > > * manage a central UUID <-> 'struct file' map that allows virtio-pipe
> > > >   to convert FDs to UUIDs, pass UUIDs through a pipe and convert those
> > > >   UUIDs back to FDs on the other end
> > > >   - we need to expose an API to let each subsystem register/unregister
> > > >     their UUID <-> FD mapping (subsystems are responsible for the UUID
> > > >     creation/negotiation)  
> > >
> > > Can you provide more detail about the envisioned scope of this
> > > framework?  
> >
> > The scope is "generic message+FD passing" interface, which is pretty
> > much what virtio-wl provides.  
> 
> I think that scope is too broad. A socket is a 'generic message+FD'
> interface. Unless there's the expectation that the interface should
> eventually be as flexible as a regular domain socket, I think it would
> be a good idea to frame the scope of the interface more precisely.

Generic message passing still stands I think (generic as in
protocol-agnostic). For the FD part, of course we won't support all
kind of FDs on day 1, but the idea is to abstract things so we can
extend the solution easily.

> 
> Part of this ambiguity comes from the informal usage of the term 'FD'.
> An FD is a concept in Linux and other operating systems (and not even
> all operating systems - e.g. Fuchsia). At present, FDs are not a
> concept in virtio. Talking about sending FDs over virtio handwaves a
> lot of details about what that's actually going on.

Correct, we're actually not passing Linux FDs at the virtio level,
we're passing resource handles, but I note that those handles are
called VFD (Virtual File Descriptor) in the virtio-wayland too :).

> 
> > > How
> > > do operations on the guest FD affect the host FD, and vice versa?  
> >
> > Depends what you mean by operations. If we're talking about regular
> > read/write/ioctl/mmap operations on the guest side, it's up to the
> > subsystem/driver to implement the expected behavior.  
> 
> I think part of my confusion comes from the fact that virtio-wayland
> seems to provide both the IPC mechanism described for virtio-ipc as
> well as some additional guest/host file sharing support.

I guess that'd be another kind of resource, and would require a
specific implementation, yes. Is it related to what Gerd was mentioning
with virtio-fs?

> If that is
> actually the case, then I guess a striped down version of
> virtio-wayland would still be necessary.

Maybe, until we add support for this file sharing feature upstream.
I'll have a closer look at how file sharing is exposed by virtio-wl.

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2020-02-27 11:51 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-07 17:28 [virtio-dev] [RFC] Upstreaming virtio-wayland (or an alternative) Boris Brezillon
2020-02-10  5:06 ` [virtio-dev] " David Stevens
2020-02-17 10:02   ` Boris Brezillon
2020-02-17 10:22     ` David Stevens
2020-02-10 13:38 ` Gerd Hoffmann
2020-02-10 16:09   ` Stefan Hajnoczi
2020-02-17 10:28   ` Boris Brezillon
2020-02-17 12:32     ` Gerd Hoffmann
2020-02-17 13:44       ` Boris Brezillon
     [not found] ` <CADMs+9YC3QHOsmsB9pjA-AFC+fc=_a+tSqBbDsecNvkhBc85Dw@mail.gmail.com>
2020-02-17 11:02   ` Boris Brezillon
2020-02-17 13:58 ` Boris Brezillon
     [not found]   ` <CAFNex=BuHdsEjFK3_cTqO2nOE-kB_MSH26sCTekF_6AK8Fyv3Q@mail.gmail.com>
2020-02-17 18:21     ` Boris Brezillon
     [not found]       ` <CAFNex=A8fU3e=FYP=t7jQ0J2E5aoyGKujhj8Df+vOhkzV8etgA@mail.gmail.com>
2020-02-19  8:52         ` Boris Brezillon
2020-02-24 10:33       ` Boris Brezillon
2020-02-24 12:12         ` Gerd Hoffmann
2020-02-24 12:45           ` Boris Brezillon
2020-02-24 13:18             ` Boris Brezillon
2020-02-24 13:42               ` Gerd Hoffmann
2020-02-24 13:57                 ` Boris Brezillon
2020-02-24 14:25                   ` Boris Brezillon
2020-02-24 13:35             ` Gerd Hoffmann
2020-02-24 12:32       ` Gerd Hoffmann
2020-02-25 15:21 ` [virtio-dev] " Boris Brezillon
2020-02-25 15:55   ` Alex Bennée
2020-02-26  9:25     ` Boris Brezillon
2020-02-26 15:12   ` Gerd Hoffmann
2020-02-26 17:05     ` Boris Brezillon
2020-02-27 10:29       ` Gerd Hoffmann
2020-02-27 12:24         ` Boris Brezillon
2020-02-27  4:20   ` David Stevens
2020-02-27  9:09     ` Boris Brezillon
     [not found]       ` <CAFNex=C4wm7=iH9XmyHoTSdkDfA3vbFOuLaaQ4aLjE9keu_NDg@mail.gmail.com>
2020-02-27  9:33         ` Boris Brezillon
2020-02-27 11:14       ` David Stevens
2020-02-27 11:51         ` Boris Brezillon [this message]
2020-02-27 14:43         ` Gerd Hoffmann
2020-02-28  8:04           ` Boris Brezillon
2020-02-28  9:27             ` Gerd Hoffmann
2020-02-28 10:11               ` David Stevens
2020-02-28 10:30                 ` Gerd Hoffmann
2020-03-02  2:24                   ` David Stevens
2020-03-02  9:28                     ` Boris Brezillon
2020-02-28 10:31                 ` Boris Brezillon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200227125108.52873611@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=alexandros.frantzis@collabora.co.uk \
    --cc=kraxel@redhat.com \
    --cc=marcheu@chromium.org \
    --cc=stefanha@redhat.com \
    --cc=stevensd@chromium.org \
    --cc=tfiga@chromium.org \
    --cc=tomeu.vizoso@collabora.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=zachr@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.