trace: move xtos/include/sof/trace/preproc*.h to app level (and change default for CONFIG_TRACE) (OPTION A)

[kv2019i]

UPDATE: alternative implementation to this PR -> #9603

trace: make CONFIG_TRACE=n the default for Zephyr builds
trace: move xtos/include/sof/trace/preproc*.h to app level

Link: #9015

See also #9597 to make sof-logger dependent code more clearly separated.

[lgirdwood]

@kv2019i do we really want to bring back these headers into common lib ? we want to make these deprecated and remove alongside with xtos support.

[kv2019i]

@lgirdwood wrote:

@kv2019i do we really want to bring back these headers into common lib ? we want to make these deprecated and remove alongside with xtos support.

That is a good question. I did initially try to just make preproc.h unavailable in Zephyr builds (to implement #9015, this preproc.h is one of the last blockers to enable strict headers mode for Zephyr builds), but hit soome surprising issues. It seems there are two uses of preproc.h in SOF Zephyr builds, one that hits already in CI:

1. the "no logging build" with Zephyr. In current main, build for imx8 (board imx8mp_evk/mimx8ml8/adsp) fails if I don't have the preproc.h family of headers (either via xtos headers or via app layer). It seems this really depends on specific implementation of SOF_TRACE_UNUSED that does not trigger unused warnings by compiler and this is implemented in the moved preproc headers. This is used in a lot of places and is specific to SOF macros like comp_info() et al.

2. possibility to start Zephyr migration by using sof-logger (before you have a Zephyr backend for your platform). This is still supported in the code and we did use it at Intel in early Zephyr work. It's not the greatest tool as one cannot see Zephyr/driver side logs this way, but as a transition tool it had its uses. No current CI target is depending on this.

While contemplating on how to address 1+2, I figured maybe better to have the preproc.h stuff in one place (now it's split between app level trace.h and rtos headers) and gate it with build options to use DMA-trace (or the SOF special build with no logs that uses preproc.h as well). These headers would not have effect unless you have (CONFIG_TRACE=y || CONFIG_ZEPHYR_LOG=n), and once we have no CONFIG_TRACE users left, the files can be removed.

I can work on an alternative PR with the assumption we drop support for sof-logger on Zephyr (2 above). If we decide on this, it might make sense to have a alternative smaller implementation for the "no logging build" problem. and keep preproc.h stuff in the old place under xtos headers. I did start on this, but then realized that if we keep (2) open, this is futile work and we need full preproc.h for Zephyr in the end still.

[lgirdwood]

I can work on an alternative PR with the assumption we drop support for sof-logger on Zephyr (2 above). If we decide on this, it might make sense to have a alternative smaller implementation for the "no logging build" problem. and keep preproc.h stuff in the old place under xtos headers. I did start on this, but then realized that if we keep (2) open, this is futile work and we need full preproc.h for Zephyr in the end still.

We should be using native Zephyr tooling for logs etc - no point in maintaining 2 sets of tools, if Zephyr log toll missing features then we should upstream them into Zephyr.

This can wait though until everyone is ready on Zephyr and xtos is removed. This would also means making all all code use native Zephyr logging APIs.

There may also be some low hanging fruit by removing unused parts of the pre-proc headers.

[kv2019i]

#9603 merged instead, closing this.