Should `System` include all system-specific configuration information?

[thanasipantazides]

Current status

LineInterface creates a bunch of System objects with communication/commanding-related members (particularly for SpaceWire-based systems). LineInterface also creates several std::unordered_map<>s to lookup timing information, endpoint (Ethernet interface) information, etc for each System::hex value.

The buffer issue #27 necessitate more std::unordered_map<>s for looking up packet size limits (MTUs), System-specific packet buffers, etc. So I'm thinking it may be nice just to do these things:

To do

• [x] Include packet MTU information in foxsi4-commands/systems.json. Do this for all ethernet_interfaces.
• [x] Consider including (SPMU-001-specific) Ethernet header length information in systems.json as well (to fully define PacketFramer).
• [x] Add MTU/max data payload member to EndpointData.
• [x] Add members to System:
  • [ ] TimeData System::time_data
  • [ ] EndpointData System::endpoint_data
  • [ ] Some lookup of frame size by Command, or a small list of predefined (like housekeeping and events) data frame sizes (for building FramePacketizer and PacketFramer).
  • [ ] Possibly PacketFramer? This takes the place of the map of RingBufferInterfaces, but also introduces circular dependency.
• [x] Modify LineInterface to populate generated System objects correctly.

[thanasipantazides]

Also related to #27, how does this affect use of RingBufferInterface map by TransportLayerMachine? Is there an extension of PacketFramer that obviates RingBufferInterface, or do we need both?

[thanasipantazides]

Re: RingBufferInterface and PacketFramer: would just need to add two fields:

1. PacketFramer::start_address or PacketFramer::remote_buffer_offset to track the start point of remote ring buffer memory, and
2. PacketFramer::remote_buffer_size or something to track the length of the System's ring buffer.

[thanasipantazides]

In the current implementation of PacketFramer, could get the desired RingBufferInterface-like behavior by accessing PacketFramer.system.ring_params. But would need to manage iteration through remote memory in calling context, i.e. a TransportLayerMachine::handle_cmd() or something should check the write pointer and iterate through read positions.

This is assuming the PacketFramer/RingBufferInterface is used for single-frame reads. The original intention of RingBufferInterface was to facilitate reading multiple frames in a batch. That responsibility is also delegated to the calling context in the current PacketFramer implementation.