rpmsg: exposing the bus to userspace

[Matteo Sartori <matteo.sartori@t3lab.it>]

Hi,

I have been working on remoteproc/rpmsg and FreeRTOS/OpenAMP for the
latest three months and recently, with my colleagues, I have started
reasoning about the best possible way to expose the kernel rpmsg bus
to applications running in user space. The idea is to end up with a
clean mechanism for the user-kernel communication, like sockets or
char devices, in order to build AMP applications on top of it.

In fact, we have been running experiments with some out-of-tree
drivers implementing exactly such interfaces, namely a driver
registering a new address family AF_RPMSG for the socket interface,
from Texas Instruments, and a char device driver representing
different rpmsg channels with /dev/rpmsgX special files, found inside
OpenAMP obsolete directory.

I am quite new to kernel development and in particular to remoteproc
subsystem, so I am asking the following questions because maybe I have
missed some past developments and discussions about this topic. I
apologize if this is the case.

- Have you ever considered the inclusion of these out-of-tree modules
  in the mainline?
- If so, have you planned some work on this, or what are the reasons
  for not including these modules?
- Is there already a preferred way for exposing the rpmsg bus for
  generic services to userspace, or is more suitable the idea to have 
  a different rpmsg driver, therefore a user-kernel communication strategy, 
  for each different use case of the bus?

Anyway, I would be very glad to contribute in the direction of an
appropriate user-kernel interface for accessing the rpmsg bus, and at
the moment I have a working test case for the socket driver as well as
for the char driver. Given the fact I don't see the superiority of one
approach compared to the other, I would like to propose and discuss
with you both of them.

This was kind of an introductory email. I am preparing two patchsets.

Best regards,
Matteo