libmetal is too big/complex for normal RTOS usage
Opened this issue · 1 comments
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.
This issue has been marked as a stale issue because it has been open (more than) 45 days with no activity.