Closed schilkp closed 1 month ago
@aggarg Sorry I seem to have removed your suggestions when fixing the uncrustify fails. They are incorporated now.
I wasn't aware that your commits would somehow end up on my fork/could get overwritten when I force-pushed to my own fork.
For the record: https://github.com/FreeRTOS/FreeRTOS-Kernel/commit/faa28781602152624b588711bec9dba7a5fd5599
Issues
0 New issues
0 Accepted issues
Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code
Attention: Patch coverage is 75.00000%
with 1 lines
in your changes are missing coverage. Please review.
Project coverage is 92.31%. Comparing base (
8c49c54
) to head (c72f612
). Report is 33 commits behind head on main.
Files | Patch % | Lines |
---|---|---|
queue.c | 75.00% | 1 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Description
The current hooks were not effective at allowing a tracer to track the number of items in a queue, since it could not differentiate between a queueOVERWRITE, queueSEND_TO_BACK, and queueSEND_TO_FRONT send, and could not (efficiently) trace a queue reset.
For sends, this adds extended tracing macros that, if not implemented, fall back on the original tracing macros for backwards compatibility, and introduces a new traceQUEUE_RESET hook.
Discussed here: https://forums.freertos.org/t/queue-tracing/20054/4
Test Steps
No unit test regressions. My work-in-progress tracer can access the required information.
Checklist:
I am not aware of any tracing test infrastructure, but would be happy to update it if it is pointed out to me.
Similarly if there is any documentation that I can work on updating, please let me know and I am happy to do so.
Related Issue
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.