Discussion of the implementations of VIRTIO specification
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox