Improve consistency and reduce duplication in various BSP/PSP implementations

[skliper]

Currently in the CFE/OSAL world we have at least four different platform-specific abstraction methods, all of which basically do the same thing of getting common code to run on a different platforms. All of these provide three very basic bits of functionality, in different flavors:

• provide a well-known entry point symbol for the platform (main, Init, etc)
• get the system into a proper state for running the app
• Invoke OS_Application_Startup() -- or whatever the real app entry point is
• Do something for idle time while the app runs (a shell, or just an idle loop).
• Shut it down when complete

Provider 1:

On the OSAL side this is provided by the "BSP". It has genppc-vxworks6.4, pc-linux, pc-rtems, sparc-vxworks6.7, sis-rtems, and mcf5235-rtems (the latter 3 are somewhat unmaintained/untested).

Provider 2:

When running Unit tests, an alternative OSAL BSP is used which has extra functionality for running the tests. The idea is that any platform capable of running applications should also be capable of running Unit tests.

Unfortunately, to avoid changing existing BSP functions, this was "cloned" and therefore this has basically morphed into a second duplicate provider of the entry point/startup/shutdown logic, because UT needs a slightly different setup from a regular app. There still is, however, a considerable amount of overlap between the "UT" BSP and the regular application BSP.

//Proposal//: These should be made into an extension of the basic OSAL BSP.

Provider 3:

The CFE PSP also provides many of the same services. On the CFE PSP repo, there are "pc-linux", "pc-rtems", and "mcp750-vxworks6.4".

These are basically extended versions of the OSAL BSP, and also provide entry point/shutdown logic, but they also do ADDITIONAL configuration that is specific to CFE before calling the CFE entry point.

//Proposal//: like the unit tests, the CFE PSP should be an extension of the OSAL BSP, not a replacement for it. The PSP already defines a CFE_PSP_Main() entry point for itself, and this can be invoked as a second-stage after OS_Application_Startup to do the additional startup tasks required for CFE.

Provider 4:

The JSC-provided unit tests residing in the osal/src/unit-tests directory contain their own platform abstractions by way of preprocessor macros and alternate header/source files. The source/header file choice is based off the _LINUX_OS_, _VXWORKS_OS_, and OSP_ARINC653 compile-time macros. In turn, this defines additional macros for platform-specific routines like sleep / logging / taskDelay, etc.

These tests are already using an entry point provided by the UT-BSP described in (2) above, the macros supplement this. The problem is that not all platforms are provided. Most notably, there is no implementation for RTEMS_OS, so these tests are currently unbuildable on PC-RTEMS.

//Proposal//: Functions like sleep/delay and other platform-specific bits should be changed from a macro to an API call provided by the UT-BSP. Logging functions are already provided by the UT-BSP. Furthermore, all the test cases should use UtAssert calls to make the output consistent with everything else.

[skliper]

Imported from trac issue 238. Created by jphickey on 2019-08-20T15:38:25, last modified: 2019-08-20T15:38:25

[jphickey]

This issue needs to be addressed in several parts/iterations:

1. Items 1 & 2 above can be addressed by combining the regular OSAL BSP and the UT BSP into a single BSP. In order to do this the entry point for UT needs to be different than that of a normal application i.e. so the common UT-Assert code provides the normal "app" entry point, and the test code provides the "test setup" entry point. This separate entry point done in Alternative entry point for UT-Assert based test applications #294.
2. The JSC unit tests (item 4 above) are converted to use UT assert in Code in "unit-test" should use UT Assert #313

Once these two items are complete then the only remaining item is the PSP (item 3 above) which, if deemed worthwhile to fix, could be done as a CFE/PSP change.

[skliper]

See nasa/PSP#121 for item 3.

[skliper]

@jphickey Looks to me like 1, 2, and 4 are done, and 3 is in nasa/PSP#121. Can this issue be closed?

EDIT - fixed issue reference

[jphickey]

We need to merge changeset f980c1f first. Haven't created a PR just yet, as I wanted to confirm that this change does not adversely affect other items I'm working on in parallel. But otherwise it is basically ready.