Support low-level transport access

[pavel-kirienko]

Imagine an ARINC-653-style unit running some logic on bare metal alongside with several virtualized applications sharing the same hardware. Suppose that the hardware is connected to a UAVCAN bus, and the host runs a UAVCAN node. If the virtualized components choose to share the same UAVCAN node with the host system, they will require a well-defined interface for exchanging data between the host-bus connection and their own applications. Since the host system is exceedingly unlikely to be aware of the types of data used by virtualized components, the interface should be made data-type-agnostic, yet we don't want to unnecessarily burden the virtualized components with maintaining more of the UAVCAN protocol stack than needed; rather, we should strive to facilitate reliance on the parts of the protocol stack already implemented on the host.

A possible solution is to let the virtualized systems perform DSDL object serialization on their own, thus effectively eliminating the type information, and interact with the UAVCAN bus by cutting directly into the transport layer of the host's stack. So that, for example, when a virtualized application needs to emit a particular transfer, it would serialize it internally and then hand over the chunk of bytes to the host accompanied by the port-ID, destination node-ID, priority, and whatever else is needed to let the transport layer dispatch the data correctly. Data reception is the reverse of that: the virtualized application instructs the host which port-ID it is interested in, and the host takes care to route all incoming transfers accordingly.

I think the implementation should be fairly trivial if the logical coupling between the data serialization logic and the transport layer is sufficiently low. Here is a helpful diagram copy-pasted from PyUAVCAN docs; the described interface would be attached directly under the "presentation" layer:

[thirtytwobits]

I completely agree and was basically going to support this anyway. I do like namespacing the serialization separately and was working on a "marshal" namespace for this. Presentation is overloaded because of MVP frameworks but I suppose it's correct based on the OSI model.

[pavel-kirienko]

This is designed-in, see #333