Fix #797, refactor internal table/id management

[jphickey]

Describe the contribution
Introduce wrapper/accessor functions to look up table entries by ID for ES & EVS subsystems.

Do not use AppID as a table index.

Note - This does not change existing external APIs and AppIDs are still zero-based uint32. This only changes the internal
structures to remove use of ID as an array index, and to use a lookup function to locate the table entry from an ID. All entry access is then performed via the table entry pointer, rather than as an array index.

This provides the groundwork for abstract IDs without actually changing anything fundamental about resource IDs.

Fixes #797

Testing performed
Build and sanity check CFE - start up apps and send commands, confirm normal operation
Run all unit tests.

Expected behavior changes
No impact to behavior - internal refactoring only.
API additions to support more abstract resource IDs.

System(s) tested on
Ubuntu 20.04

Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.

[astrogeco]

Would it be easier to review this by splitting it up into a couple of separate commits?

[jphickey]

Would it be easier to review this by splitting it up into a couple of separate commits?

I could probably split into a separate commit for each subsystem (ES, EVS, SB, etc) if that helps?

[astrogeco]

That might be helpful, I like atomized commits as much as possible. The subsystem approach makes sense

[jphickey]

OK - separate commits for each subsystem. ES is still the biggest one as its where the bulk of changes lie.

Note that most changes are mechanical -- that is, changing something like CFE_ES_Global.AppTable[AppID].something into AppRecPtr->something instead. The idea here is that all this internal stuff needs to be cleaned up first which shouldn't change anything other than make it consistently apply the lookup function to get/change internal data.

Externally the API uses the abstract AppID (uint32) but internally (after validation of said AppID) we can pass around a pointer to the entry instead, avoiding repeat lookups and clean up the code substantially.

[astrogeco]

CCB 2020-09-02

• Expand comments to note the justification of why AppID does not need to be re-validated internally in ES
• Note substantial changes to Unit Tests
• New function CFE_ES_GetTaskID() usage versus OS_TaskGetId() warrants more discussion due to naming and scoping. Need to find a new name for task.

[astrogeco]

@jphickey should we convert this to draft while working on the rename of CFE_ES_GetTaskID?

I suppose we can do that, but I hope this doesn't become a long drawn-out thing .... The more I think about it since the CCB the more I think that changing the name from "task" would only add confusion since we have many existing (public) APIs that refer to "task" in their name:

• CFE_ES_GetTaskInfo
• CFE_ES_CreateChildTask
• CFE_ES_RegisterChildTask
• CFE_ES_ExitChildTask
• CFE_ES_DeleteChildTask
• CFE_ES_IncrementTaskCounter

Changing the name of all of these would be a huge backward compatibility issue. And these are all referring to ES-scope tasks (because they are in CFE ES) and they are largely wrappers around OSAL with extra ES sauce on top.

The fact that apps went direct to OSAL for the one missing ES task routine (OS_TaskGetID()) really just seems more odd when you think about.

Adding CFE_ES_GetTaskID() that mirrors the existing CFE_ES_GetAppID() just completes the ES task API. All task IDs at this level (and beyond) are ES tasks.

[jphickey]

In regards to the original concern about differentiating OSAL tasks from ES tasks -- the more I think about this, I don't think we really need to do this via a different name, because these two should really never be mixed. The fact that they are mixed now is actually the problem that this PR is fixing.

Moving forward -- all tasks at the CFE level and above should be ES tasks, and all management of those tasks should happen though ES APIs. There really shouldn't be any areas where OSAL task IDs are intermixed with ES task IDs. They should all be ES task IDs - EXCEPT, of course, in OSAL itself, and the ES APIs that actually call OSAL.

[skliper]

Copy, I think if it's all ES tasks then it's fine.