From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-6809-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id B143A985EB4 for ; Fri, 28 Feb 2020 10:11:55 +0000 (UTC) MIME-Version: 1.0 References: <20200207182842.770bfb27@collabora.com> <20200225162105.1912fae0@collabora.com> <20200227100951.19e5c8df@collabora.com> <20200227144322.qasfqiyg47vfcqur@sirius.home.kraxel.org> <20200228090404.656686c5@collabora.com> <20200228092757.mvcm3c5rbafloold@sirius.home.kraxel.org> In-Reply-To: <20200228092757.mvcm3c5rbafloold@sirius.home.kraxel.org> From: David Stevens Date: Fri, 28 Feb 2020 19:11:40 +0900 Message-ID: Subject: Re: [virtio-dev] [RFC] Upstreaming virtio-wayland (or an alternative) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To: Gerd Hoffmann Cc: Boris Brezillon , Stefan Hajnoczi , Zach Reizner , =?UTF-8?Q?St=C3=A9phane_Marchesin?= , Tomeu Vizoso , Tomasz Figa , virtio-dev@lists.oasis-open.org, Alexandros Frantzis List-ID: > > > Yes, sure, we need to exactly specify the different kinds of file > > > handles / resources. I think it makes sense to have a virtio feature > > > flag for each of them, so guest+host can easily negotiate what they a= re > > > able to handle and what not. > > > > I was expecting that to be a feature of the resource producers > > (virtio-gpu, virtio-fs, ...) rather than a feature of virtio-ipc > > itself. > > "resources from other virtio devices" would be one virtio-ipc feature > flag. And, yes, that would for the most part have the other device > handle the problem. > > But there also is "unix socket", or maybe a somewhat broader "stream", > which would be another feature flag I guess because virtio-ipc would > just tunnel the stream without the help from other devices. Can you elaborate on what you mean by this? I can envision how virtio-ipc would be a generic mechanism for passing data+virtio resources, including any new types of resources it itself defines. However, if "unix sockets" or a generic "stream" expands beyond virtio, that seems too broad, with too many edge cases to be feasible to implement. -David --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org