Update build scripts so only CFE_SYSTEM_PSPNAME needs to be specified

[jphickey]

Is your feature request related to a problem? Please describe.
Currently when cross compiling the user-supplied scripts/toolchain file need to specify three configurations:

• CFE_SYSTEM_PSPNAME
• OSAL_SYSTEM_BSPTYPE
• OSAL_SYSTEM_OSTYPE

However, although an OS layer can have multiple different BSP/PSP layers, each PSP only works with a specific OS layer.

Describe the solution you'd like
The CFE build should only require that CFE_SYSTEM_PSPNAME is specified. It should automatically choose the right OSAL OS/BSP layers that correspond to that PSP.

Describe alternatives you've considered
Leaving it as-is has a potential for mismatching incompatible layers.

Requester Info
Joseph Hickey, Vantage Systems, Inc.

[joelsherrill]

Is the BSP name sufficiently precise to imply the OS and architecture? Supporting cFE for multiple OSes on the same hardware seems likely.

And even though it seems unlikely, we have seen cases with RTEMS where the same board name was used across multiple processor architectures. This is why formally within RTEMS we use ARCHITECTURE/BSP such as sparc/leon3.

And this sounds remarkably like a proposition to come very close to re-inventing the target nomenclature of the GNU Project. Most of the time, you see only CPU-ARCHITECTURE with an optional version on the end but formally, it is CPU-VENDOR-ARCHITECTURE[VERSION]. In this case, you could use vendor to denote the BSP. Doing this would result in sparc-leon3-rtems4.10 or arm-raspberrypi-rtems5.

Just a warning that there be small dragons that need to be considered.

[jphickey]

It is the CFE PSP which implies both an OSAL BSP and, by extension, OSAL OS layer to use with it. CPU Architecture is separate and this is done via a CMake toolchain.

In typical use cases the cmake toolchain is actually the place where CFE_SYSTEM_PSPNAME is specified, and this also specifies the full compiler tuple (e.g. i686-rtems4.11 as an example). However this is not strictly required to pair this with a PSP, it is just out of convenience to do it this way.

So the flow becomes:
Toolchain file (e.g. in - nomenclature, such as i686-rtems4.11)
implies -> CFE_SYSTEM_PSPNAME (e.g. "pc-rtems")
implies -> OSAL_SYSTEM_BSTYPE (e.g. "pc-rtems")
implies -> OSAL_SYSTEM_OSTYPE (e.g. "rtems")

Under this pattern the same PSP could not be used on the same hardware with a different OS. But all PSP's are hardware and os-specific currently. However, In the future, it is being considered to make PSP more modular so a "PSP" is only a collection of modular low-level services. This would in turn allow the same board to be used with different OS's.

Notably a raspberry pi can probably run any of the three OS's (VxWorks, RTEMS, and of course linux) but these would all necessitate a different implementation of the PSP-provided services. Where it isn't different, the modular approach can allow re-use of the code without cloning it.

So I think this is all covered?

[joelsherrill]

In spite of some cFE training (thanks guys), I still am not knowledgeable enough on it to so "OK". :)

If a few of you all think it is covered, I concur. I just wanted to point out the issue.

Just be sure to include enough information where multiple versions of the same OS can be supported. I suspect cFE RTEMS users will be split between 4.10 and 5.1 for a long time. And that does imply differences in the API set and SMP support available in RTEMS.