| Message ID | 20200515205642.13529-1-mathieu.poirier@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | rpmsg: core: Add support for name extension | expand |
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? 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 >
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 >>
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 >>>