OSAL headers define a shared memory API that is not actually implemented anywhere

[jphickey]

Describe the bug
The osapi-os-core.h header defines several prototypes e.g. OS_ShMemCreate(). However, these functions are not implemented anywhere, and are not used by CFE nor CFS apps.

To Reproduce
N/A - this is unused code.

Expected behavior
The headers should not include these prototypes if they are not implemented and there is no plan or requirement to implement them.

Code snips

/*
** Shared memory API 
*/
int32 OS_ShMemInit          (void);
int32 OS_ShMemCreate        (uint32 *Id, uint32 NBytes, const char* SegName);
int32 OS_ShMemSemTake       (uint32 Id);
int32 OS_ShMemSemGive       (uint32 Id);
int32 OS_ShMemAttach        (cpuaddr * Address, uint32 Id);
int32 OS_ShMemGetIdByName   (uint32 *ShMemId, const char *SegName );

System observed on:
Ubuntu 18.04 (64-bit)

Reporter Info
Joseph Hickey, Vantage Systems, Inc.

[skliper]

I'd assume these are here to define the API, similar to the memory/port/EEPROM prototypes that don't really do the unique work expected for custom hardware. Likely still useful if this is specifying what the prototypes would need to be, and the framework supported OSALs could define the functions as not implemented.

Maybe @acudmore or @jwilmot could provide more context, but I'd be inclined to leave them in if the intent is to define the API (knowing not all OSALs implement every API).

[jphickey]

I would argue that if this would fit better as a PSP module akin to the memory/port/EEPROM code. It can then be modularized and selectively included in the PSP for platforms that may utilize shared memory.

However, it doesn't make much sense at this layer of OSAL, which is supposed to be for common, abstract services that all RTOS implementations should provide. Shared memory is a concept that only applies to targets with virtualized memory spaces.

I would recommend for removal of the APIs from this file, and they can be re-introduced with the PSP when an use-case is identified. The use case is quite important, as this is the only way to determine whether the proposed API will be sufficient to cover it.

I went back as far as OSAL 3.3, I have older archives on a backup disk that I wanted to look up.
But do not think we ever had an implementation for the shared memory API, and I cannot currently think of a reason to keep it here.
It might have had roots in an attempt to work in a memory protected architecture, where each cFE subsystem (SB, etc ) could have exposed global/shared memory as a shared segment to the operating system. On a single address space OS, it would have been a no-op.

[skliper]

Sounds good, I'm in concurrence with removing these from the OSAL API and that it would be more appropriate at PSP level if it becomes a requirement.

[skliper]

Note also no functional tests... (no issue as long as we get these removed).