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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux