[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]