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:8.497 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site