[PATCH 0/1] rpmsg: char device for exposing channels to userspace

[PATCH 0/1] rpmsg: char device for exposing channels to userspace

[Matteo Sartori]

Hi,

The canonical method for getting access to the rpmsg bus is to write a specific
driver that manages memory and user-kernel communication as the given
application requires.
This patch instead proposes a simpler and general approach in which the rpmsg
bus, specifically only matched channels, are exposed to userspace through char
devices.

As previously discussed, this approach has the problem of not supporting the 1:N
communication type, where a single program can act like a server that receives
requests from multiple users on a given port. Sockets with bind() and recvfrom()
could better serve this scheme.

However, I propose a chardev strategy that matches quite well with the rpmsg
channel concept. The driver registers itself on the bus with a specific channel
name, "rpmsg-char-dev", and upon matches with discovered devices, allocates and
creates new char devices that reflect newly created rpmsg channels.
Given the fact the rpmsg channel concept belongs to 1:1 communication styles
I would say this is a cheap and simple solution for exporting generic services
to userspace.

The code has been derived from OpemAMP repository
  https://github.com/OpenAMP/open-amp
at the location
  obsolete/system/linux/kernelspace/rpmsg_user_dev_driver/rpmsg_user_dev_driver.c

A counterpoint is that we need an auxiliary buffer to store received rpmsg
messages in. The rpmsg mechanism is asynchronous because a callback get called
upon reception and so we need to copy the message to an intermediary location
in order to free the underlying rpmsg buffer.
An important point to stress is that the actual strategy drops the message if
the kfifo is full.
For the write() case I see a similar problem because there is again a copy from
user to kernel memory prior to sending, a call copy_from_user(), but I believe
this is easier to remove for increasing performances.

Another problem could be about naming: how do I know which is my destination if
there are more than one matched channels? For example, the systems loads two
remotes that both subscribe with the "rpmsg-char-dev" channel and I have to talk
with one of them, specifically. Which is the right target, rpmsg0 or rpmsg1?
I believe such information can be found under sysfs.

The discussion is still going on, but I wanted to illustrate such ideas with a
concrete patch proposal.

Best regards,
Matteo

Matteo Sartori (1):
  rpmsg: driver which exposes channels through char devices

 drivers/rpmsg/Kconfig         |   7 +
 drivers/rpmsg/Makefile        |   1 +
 drivers/rpmsg/rpmsg_chardev.c | 335 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 343 insertions(+)
 create mode 100644 drivers/rpmsg/rpmsg_chardev.c

-- 
2.7.4