-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zephyr preproc.h implementation (OPTION B) #9603
Changes from 4 commits
915dc23
5bbaa1e
6ec9590
40f0911
6e167ca
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,24 @@ | ||
/* SPDX-License-Identifier: BSD-3-Clause | ||
* | ||
* Copyright(c) 2024 Intel Corporation. | ||
*/ | ||
|
||
#ifndef __SOF_TRACE_PREPROC_H__ | ||
#define __SOF_TRACE_PREPROC_H__ | ||
|
||
#ifdef CONFIG_TRACE | ||
#error "SOF dma-trace (CONFIG_TRACE) not supported in Zephyr builds. \ | ||
Please use CONFIG_ZEPHYR_LOG instead." | ||
#endif | ||
|
||
#ifndef CONFIG_ZEPHYR_LOG | ||
|
||
/* | ||
* Unlike the XTOS version of this macro, this does not silence all | ||
* compiler warnings about unused variables. | ||
*/ | ||
#define SOF_TRACE_UNUSED(arg1, ...) ((void)arg1) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. doesn't silence all - is it because of the lack of recursion? Leaving the rest of the arguments without There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @lyakh Ack, in "OPTION A" (9598) there's "full silencing implementation". preproc-*.h does just this and question is whether to move that out of XTOS code or remove it, and Liam was not keen to have this in SOF main library. I'd say, if you want full silencing, then just pull in preproc-*h, it's does just the thing, has the recursion helpers to iterate through the varargs in preprocessor. Looking at the code base, there's actually much less use of this than I thought (in common code at least), so just requiring callers to use __maybe_unused seems not so impractical after all. And for sure easier to maintain code in SOF tracing layer (that we want to minimize). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the first argument to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @lyakh This is really a very niche scenario of building with Zephyr but disable Zephyr logs (and fully disable, not just limiting logs to error level or something more usual). Now in Zephyr, logs are disabled like
In "old SOF", there has been more elaborate macro magic that disables unused variable warnings even if a local variable is only used in "comp_dbg(comp, "print local variable foo %d", foo)" statements. Now we could handle this in multiple ways:
I guess there are more variants of (1), but I'd say it's not worth the effort to make this pretty (especially as Zephyr does not do it). raio. You are building with Zephyr but with Zephyr logging subsystem disabled (and fully disabled, not just limiting to plain error logs like we do on some targets). Zephyr headers take care of the |
||
|
||
#endif /* CONFIG_ZEPHYR_LOG */ | ||
|
||
#endif /* __SOF_TRACE_PREPROC_H__ */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At first I didn't like this, because it adds less than pretty code to potentially many locations (we need to handle information-, warning- and error-level messages similarly, right?), but then I thought, that if we have an automated way to identify all these locations, then maybe this is the best way to handle them. Firstly it's honest and explicit - it helps keep track of such cases and maybe avoid adding variables that can easily be avoided. The same holds for variables, only used in
assert()
calls, right? So, yes, I'd buy this.