Hi Vincent, On Thu, Sep 17, 2020 at 10:36:44AM +0200, Vincent Whitchurch wrote: > On Thu, Sep 17, 2020 at 07:47:06AM +0200, Guennadi Liakhovetski wrote: > > On Tue, Sep 15, 2020 at 02:13:23PM +0200, Arnaud POULIQUEN wrote: > > > So i would be agree with Vincent[2] which proposed to switch on a RPMsg API > > > and creating a vhost rpmsg device. This is also proposed in the > > > "Enhance VHOST to enable SoC-to-SoC communication" RFC[3]. > > > Do you think that this alternative could match with your need? > > > > As I replied to Vincent, I understand his proposal and the approach taken > > in the series [3], but I'm not sure I agree, that adding yet another > > virtual device / driver layer on the vhost side is a good idea. As far as > > I understand adding new completely virtual devices isn't considered to be > > a good practice in the kernel. Currently vhost is just a passive "library" > > and my vhost-rpmsg support keeps it that way. Not sure I'm in favour of > > converting vhost to a virtual device infrastructure. > > I know it wasn't what you meant, but I noticed that the above paragraph > could be read as if my suggestion was to convert vhost to a virtual > device infrastructure, so I just want to clarify that that those are not > related. The only similarity between what I suggested in the thread in > [2] and Kishon's RFC in [3] is that both involve creating a generic > vhost-rpmsg driver which would allow the RPMsg API to be used for both > sides of the link, instead of introducing a new API just for the server > side. That can be done without rewriting drivers/vhost/. Thanks for the clarification. Another flexibility, that I'm trying to preserve with my approach is keeping direct access to iovec style data buffers for cases where that's the structure, that's already used by the respective driver on the host side. Since we already do packing and unpacking on the guest / client side, we don't need the same on the host / server side again. Thanks Guennadi > > > [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=338335 > > > [2]. https://www.spinics.net/lists/linux-virtualization/msg44195.html > > > [3]. https://www.spinics.net/lists/linux-remoteproc/msg06634.html
