libmetal is too big/complex for normal RTOS usage

[wmamills]

libmetal was designed to make Linux user space and RTOS and bare-metal have the same API.
This works and the amount of abstraction present is required for Linux user space (uio & vfio etc).

HOWEVER, when viewed from the perspective of only bare-metal and RTOS the library is heavy weight and overly abstract.

We should find a way to skinny down libmetal for the common case of bare-metal and RTOS. Some people have suggested a different code base with the same API but we should also look at a common code base with A compiler time flag to select the model desired. Make the default the simple model for bare-metal and RTOS platforms.

Evaluation criteria:

• Code & data size
• Dynamic memory allocation:
  • can be made optional?
  • simple allocate only possible?
• Ease of porting to a new platform on a supporrted RTOS
  • This should be zero work, prove this is true
  • the library is pre-ported to Zephyr FreeRTOS Nuttx etc, If the RTOS works on a given platfrom libmetal should as well.
• Ease of porting to a new bare-metal platform
  • W/o the abstraction of an RTOS, some porting work is required
  • Make this as simple as possible
  • Be more prescriptive about what the bare-metal BSP provides. Give porters a clean target to fit.

[github-actions]

This issue has been marked as a stale issue because it has been open (more than) 45 days with no activity.