subsys: tracing: Add macros for tracking list operations #86801
Conversation
zephyrbot
added
Release Notes
|
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
|
@rruuaanng Can you look at the CI failure? |
|
@ubieda It looks like it's not an issue, the warning is caused by my syntax. |
Try adding it under the ForEachMacros list: Lines 34 to 85 in 0b1cff2 |
zephyrbot
requested review from
jfischer-no,
jhedberg,
keith-zephyr and
simhein
rruuaanng
dismissed stale reviews from edersondisouza and ubieda
via
ed78439
rruuaanng
force-pushed
the
track-wrap
branch
from
7771f25 to
ed78439
Compare
rruuaanng
force-pushed
the
track-wrap
branch
2 times, most recently
from
ac3c808 to
4a48a70
Compare
|
@rruuaanng would you mind rebasing? |
|
@ubieda Done :) |
|
|
||
| .. zephyr-keep-sorted-stop | ||
There was a problem hiding this comment.
minor: seems like an unrelated change
| */ | ||
| #define SYS_PORT_TRACK_NEXT(list)((list)->_obj_track_next) | ||
|
|
||
| /** |
There was a problem hiding this comment.
i see macros being added, but I do not see them being used, can you please elaborate on the usage of thos macros and why we need them?
There was a problem hiding this comment.
A large number of global variables with names like _track_list_k_xxx are exported to tracking.h. It seems that in Zephyr they're only used in tracing_tracking.c. If this kind of export is really necessary, I think we should add a wrapper macro to hide the implementation details of these variables.
(and provide a convenient way to operate on them.)
There was a problem hiding this comment.
That's the point being missed here - I don't think that _track_list_k_xxx are necessarily expected to be accessed from inside Zephyr. As I mentioned in my previous comment, external tools will be looking for these symbols, and macros won't be helpful to them, anyway.
There was a problem hiding this comment.
But if you really need to access them internally, directly referencing the symbols doesn't seem like a sensible approach (although the purpose of accessing the symbols is merely to iterate over them).
If we have these macros, we can handle all the objects in the _track_list_ more effectively.
Add a set of `SYS_PORT_TRACK_K_*` wrapper macros for visible access to the global tracking list, and a macro `SYS_PORT_TRACK_FOR_EACH` for iterating over the tracking list. Signed-off-by: James Roy <[email protected]>
|
8 participants
Add a set of 'SYS_PORT_TRACK_K_*' wrapper macros for visible access to the global tracking list, and a macro 'SYS_PORT_TRACK_FOREACH' for iterating over the tracking list.