lkml.org 
[lkml]   [2020]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v6 0/3] rpmsg: core: Add support for name extension
From
Date
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
>>>

\
 
 \ /
  Last update: 2020-06-09 00:34    [W:0.089 / U:0.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site