Re: [PATCH v6 0/3] rpmsg: core: Add support for name extension

[Suman Anna]

On 5/20/20 9:49 AM, Arnaud POULIQUEN wrote:
> Hi Bjorn,
>
> On 5/15/20 11:09 PM, Bjorn Andersson wrote:
> > On Fri 15 May 13:56 PDT 2020, Mathieu Poirier wrote:
> >
> > > This patchset adds the capability to supplement the base definition
> > > published by an rpmsg_driver with a postfix description so that it
> > > is easy to differentiate entities that use the same name service.
> > >
> > > Applies cleanly on rpmsg-next (4f05fc33bebd).
> >
> > Thanks Mathieu, this series does look good.
> >
> >
> > But before merging this, can someone show me a real example where this
> > is being/would be used? What are some real channel names and extensions?
>
> On ST side, This is something we plan to integrate in the TTY over RPMSG support.
> The use case is the support of multi-instances. We already provided to our
> customer a TTY service supporting it but without name extension.
> Some feed-backs are: how can we know which TTY instances to use to communicate
> to the expected remote application in case of multi-instance.
> A concrete example would be one instance to control a remote processor
> application, the other instance to get the remote system logs.
>
> Then in rpmsg TTY proposed for upstream the extension could also been used to
> differentiate the data from the control channels, as discussed with Mathieu
> during reviews: https://lkml.org/lkml/2020/4/3/964.
> Means the service is the TTY, the sub-services are the data and the control.
>
> An other usecase i have in mind is the management of the rpmsg flow control for
> the QOS.
> This could be reused to create a core flow control manager based on the
> service extension, which could be quite smooth in term of legacy support.
>
> Suman and Xiang(added in CC) have probably also some usecases as they
> proposed similar patches...

Yeah, this series is a result of the discussion on those prior patches, 
and maintaining compatibility for both the current in-kernel usage and 
the OpenAMP usage.

My original usecase was with an out-of-tree driver and is explained as 
part of review of those prior solution,
https://patchwork.kernel.org/comment/22850003/

I am also looking at this for future usage with the rpmsg-chrdev driver.

regards
Suman


> Regards,
> Arnaud
>
> > Regards,
> > Bjorn
> >
> > > New for V6:
> > > - Added example on how to use the new API.
> > >
> > > Thanks,
> > > Mathieu
> > >
> > >
> > > Mathieu Poirier (3):
> > >    rpmsg: core: Add wildcard match for name service
> > >    rpmsg: core: Add support to retrieve name extension
> > >    sample/rpmsg: Print out RPMSG device name extension
> > >
> > >   drivers/rpmsg/rpmsg_core.c          | 115 +++++++++++++++++++++++++++-
> > >   include/linux/rpmsg.h               |  13 ++++
> > >   samples/rpmsg/rpmsg_client_sample.c |   5 ++
> > >   3 files changed, 132 insertions(+), 1 deletion(-)
> > >
> > > --
> > > 2.20.1