Following are some of the limitations with the current rpmsg-proto implementation.
Some are inherent to the current implementation and some are forced by the rpmsg
semantics. Some of them are a result of retrofitting the framework to a legacy
TI IPC API.

1. bind() and connect() doesn't use standard socket semantics
   - bind used for Rx sockets (uses rpmsg endpoints), connect used for Tx sockets (reuses publish rpmsg device endpoint to send to)
   - all sockets need to be tied to a published rpmsg device
2. Interface is currently assymetric between Linux-side and remote-side
   - Published rpmsg device endpoint on remote needs to demultiplex the messages it got.
3. rpmsg client drivers can support multiple rpmsg devices of the same type, but
   we are forced to restrict one rpmsg-proto device per remoteproc acting as a 
   transport rpmsg channel.
4. Published rpmsg device cannot be used for receiving messages on Linux-side (used only as a server port).

Implementation Concerns:
1. Address Family identification scheme for a remoteproc
   - remoteproc core allocates dynamic id based on probe/remove order
   - Socket family needs a standard way of identifying a fixed remoteproc
   - DT rproc aliases currently used for this purpose
2. Userspace will require a socket-pair per processor to represent a single unified messaging channel for receiving messages from all cores.
3. Namespace alignment between ports and rpmsg end-points, rpmsg end-points are repeated per proc on Linux-side.