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: <bbc97b0d-b36c-c088-a972-d1d10f7eed17@st.com>
Date:   Wed, 20 May 2020 16:49:31 +0200
From:   Arnaud POULIQUEN <arnaud.pouliquen@...com>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>
CC:     <ohad@...ery.com>, <s-anna@...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

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

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