Should we deprecate the template machine

[arnopo]

This issue is related to the discussion in #346.

The template machine is defined by cmake/platforms/template-generic.cmake and cmake/platforms/template-freertos.cmake.

In lib/system/freertos/template and lib/system/generic/template, we define some default functions needed for the porting layer. This template can be used as a reference.

On the other hand, we expect SoC vendors to implement their porting layer downstream or within their projects. An example is the AMD/xilinx porting.

We need to clarify how we can make it easier for Libmetal users to port the library to their targets.

Keeping a template implementation
Relying only on documentation
Other approaches?

[tnmysh]

Here how it's done for AMD-Xilinx platforms:

1. libmetal doesn't not contain any vendor specific implementation for baremetal and freertos systems (such as template machine).

2. Instead, separate library implements libmetal's machine related interfaces: https://github.com/Xilinx/embeddedsw/blob/master/ThirdParty/sw_services/libmetal_xlnx_extension/src/lib/metal_xlnx_extension.c

3. During compiling demos, this new module library is linked: https://github.com/OpenAMP/openamp-system-reference/blob/d70936124af3459323659303f6497186f3287e21/examples/legacy_apps/machine/zynqmp_r5/CMakeLists.txt#L43

Above approach currently works for Baremetal "Generic" Machine. FreeRTOS work is still in progress.

The reason behind this approach is following:

• Machine specific implementation is needed only for systems that don't have machine specific API support such as Baremetal (Generic) or FreeRTOS.
• Linux or zephyr doesn't need to implement such APIs using vendor specific BSP, as usually OS API is enough.
• We can keep libmetal vendor API independent.

It's confusing to keep only template machine, and not having other vendor's implementation under machine directory. Instead, I suggest that template machine should be moved to vendor repository as well and linked during compiling demos as shown above.

This way, libmetal will be truly machine independent.

CC: @arnopo, @wmamills, @edmooring

[github-actions]

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