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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8e69229b-ece2-18b8-aa8c-01c105aa38bb@ti.com>
Date:   Mon, 8 Jun 2020 17:33:50 -0500
From:   Suman Anna <s-anna@...com>
To:     Arnaud POULIQUEN <arnaud.pouliquen@...com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>
CC:     <ohad@...ery.com>, <linux-remoteproc@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, Xiang Xiao <xiaoxiang@...omi.com>
Subject: Re: [PATCH v6 0/3] rpmsg: core: Add support for name extension

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
>>>