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/. > > [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
