Move SB route lookup (including insert method) to a module

[skliper]

Is your feature request related to a problem? Please describe.
Various implementations possible for message and route tables, all with associated advantages and issues.

Describe the solution you'd like
Provide the capability to replace the core implementation.

Describe alternatives you've considered
None.

Additional context
For implementations that support large MsgIds, or prefer smaller memory footprint at the cost of performance. Hashes, searches, etc.

Requester Info
Jacob Hageman - NASA/GSFC (per stakeholder request for alternate implementation)

[skliper]

Abstracting out MsgId/Route relation proposal - CFE_SB_GetRoutingTblPtr could use MsgId, with all the relation logic underneath the hood. CFE_SB_GetDestPtr could use route pointer. For the most part hide CFE_SB_GetRoutingTblIdx... shouldn't use direct access except when looping for reporting, and then could just loop the table. Also move all the related utility functions. Replace CFE_SB_RouteIdxPop_Unsync with a generic CFE_SB_AddRoute given MsgId, and CFE_SB_RouteIdxPush_Unsync is dead code for now (we no longer remove routes). CFE_SB_IsValidRouteIdx may actually go away (don't expose index directly).

cfe_sb_task.c

• CFE_SB_EnableRouteCmd - get route, get dest
• CFE_SB_DisableRouteCmd - get route, get dest
• CFE_SB_SendRtgInfo - loop through routes, not keys
• CFE_SB_SendMapInfo - loop through routes, not keys

cfe_sb_priv.c

• CFE_SB_DuplicateSubscribeCheck - use route pointer (used in one place, could get route first)

cfe_sb_init.c

• CFE_SB_InitMsgMap - TBD, at minimum move into module

cfe_sb_api.c - straight forward using same methods above, use MsgId to get route pointer..

Move the message map internal to the module... may pull some of the configuration options into the module (don't allow configuration of the message map size, it's based on supported message IDs).

EDIT - worth noting every one of these functions is internal to SB, but modularizing really makes them an interface...

[skliper]

Not planning on fixing with this change - PipeId is used as an index in multiple places, whitespace/alignment is tragic, excessive comments (in my opinion). Likely spawn follow-on PRs to clean up.

EDIT - also violates declare variables at the start of the function, fixing some where I see them but not a careful scrub

[jphickey]

Old issue #100 is for making Pipe IDs abstract/safe (which must include fixing use as index, etc).

Might be worth considering for this cycle? Since I've converted so many other resources to use abstract IDs already, seems like a natural thing to include. Could be done after the current efforts are completed, if desired.

[skliper]

Could be done after the current efforts are completed, if desired.

Low priority but likely possible, and a desirable change for consistency.

[astrogeco]

CCB 2020-10-06

Two implementation options:

• Option 1: Hard option, doing it "the right way"

  • Redesign the interface using a new module
  • Abstract the relationship between routes and message IDs

• Option 2: Easy option

  • Small fixes to the current design if we don't make it "interface safe"
  • Problems with maintenance if the routing table changes

CCB votes for the structured API method (Option 1)
@skliper can you double check the accuracy of these notes?

[skliper]

I think the key to option 1 is to keep direct access to the resource (routing table in this case) on one side of the interface. Option 2 was allowing direct access on both sides in the short term, since that's how it's done currently since today routing is an internal capability of SB. Making routing a module with various possible implementations benefits from a more defined interface between routing and SB, which is option 1. Even doing it the right way shouldn't be that much more work, I'm just lazy enough to want confirmation that the harder option is worth it from the CCB/open source point of view.