OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]