schedule: zephyr_dp_sched_app: fix build error in release builds#10954
schedule: zephyr_dp_sched_app: fix build error in release builds#10954kv2019i wants to merge 1 commit into
Conversation
kv2019i
requested review from
LaurentiuM1234,
dbaluta,
marcinszkudlinski and
pblaszko
as code owners
kv2019i
requested review from
abonislawski,
jsarha,
lyakh,
softwarecki and
wjablon1
There was a problem hiding this comment.
Pull request overview
Fixes a release-build compilation failure in the Zephyr DP user-space scheduler path by avoiding use of a thread-name-length Kconfig symbol when thread naming support is disabled.
Changes:
- Guard DP thread naming code with
#ifdef CONFIG_THREAD_NAMEto prevent referencingCONFIG_THREAD_MAX_NAME_LENwhen unavailable.
| static void scheduler_dp_thread_name_set(k_tid_t thread_id, struct processing_module *mod) | ||
| { | ||
| #ifdef CONFIG_THREAD_NAME | ||
| char name[CONFIG_THREAD_MAX_NAME_LEN]; | ||
|
|
||
| snprintf(name, sizeof(name), "DP:%#x", mod->dev->ipc_config.id); | ||
|
|
||
| k_thread_name_set(thread_id, name); | ||
| #endif | ||
| } |
jsarha
left a comment
jsarha
left a comment
There was a problem hiding this comment.
Stupid that due to lacking CONFIG_THREAD_MAX_NAME_LEN definition we need to ifdef code out, bu it is what it is.
lyakh
left a comment
lyakh
left a comment
There was a problem hiding this comment.
release builds don't define CONFIG_THREAD_NAME? Any particular reason for that?
Release builds fail when building with DP user-space implementation. Build fails as CONFIG_THREAD_MAX_NAME_LEN is not defined. Problem not affecting when building with debug enabled, and/or configurations where the feature is disabled. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
kv2019i
force-pushed
the
202606-fix-ptl-prod-build
branch
from
3ee77a4 to
1c2850d
Compare
|
@jsarha wrote:
A bit but makes sense as the k_thread_name_set() is a no-op so we'd be wasting cycles crafting a string in this case. Added a comment to clarify in V2. |
|
@lyakh wrote:
Thread name has been a debugging feature so far. @jsarha enabled it for thread analyzer (not a default option) and in SOF; it is only indirectly enabeld via CONFIG_DEBUG enabling coredump and Zephyr coredump code enabling thread info. Somebody would have to look into cost if enabling for all configs. It seems to affect logging code and potentially elsewhere, but not looked into the cost in detail. |
|
V2:
|
|
@lrudyX good to merge ? |
Release build fail when building with DP user-space implementation. Build fails as CONFIG_THREAD_MAX_NAME_LEN is not defined. Problem not affecting when building with debug enabled, and/or configurations where the feature is disabled.