| Age | Commit message (Collapse) | Author |
|
Refer to the issue described in PR #10599. This was a
temporary fix at that time.
After further research, we discovered that this issue
can be addressed using the "@cond" command supported
by Doxygen.
Since we currently do not intend to generate two sets
of documentation for UP and MP when generating Doxygen
documentation, the current solution is to generate only
MP documentation by default. For functions defined in
MP but not in UP, we will use the "@note" command in
the function's Doxygen comment to indicate whether the
function supports both UP and MP, or only MP.
Signed-off-by: Chen Wang <[email protected]>
|
|
fixed: b084503b6d "[kernel] add UP scheduler critical switch flag."
After this commit, doxygen build with warning:
include/rtthread.h:658: warning: argument 'lock' from the argument list of rt_spin_unlock has multiple @param documentation sections
include/rtthread.h:660: warning: argument 'lock' from the argument list of rt_spin_unlock_irqrestore has multiple @param documentation sections
include/rtthread.h:660: warning: argument 'level' from the argument list of rt_spin_unlock_irqrestore has multiple @param documentation sections
Rootcasue analysis:
src/cpu_up.c and src/cpu_mp.c define two identical functions.
Because the INPUT parameter in the documentation/Doxyfile currently
compiles all source files under ./src, i.e both of them, Doxygen
automatically merges the Doxygen comments for identically named
functions if it finds the content of doxygen comments different,
resulting in multiple @param.
Previously, the API comments in both files were identical, so there
was no problem. However, the b084503b6d change only modified the
comments in src/cpu_up.c but not in src/cpu_mp.c, causing problems.
Another drawback of the b084503b6d change is that Doxygen recommends
a single line for the @brief; multiple lines are not recommended.
Solution:
Given the requirement for a single line for the @brief, this issue
is relatively simple to resolve: simply list the extra content as @note.
Regarding the warning: A perfect solution has not yet been found.
One possible approach is to write a single Doxygen comment for a kernel
API with two implementations. This approach involves writing Doxygen
comments in only one file, such as src/cpu_up.c , while omitting them
in src/cpu_mp.c .
Another solution is to add API comments to include/rtthread.h , but the
RT-Thread include/rtthread.h file is already quite large, and adding
comments there would be even more cumbersome.
A temporary solution currently in use is to ensure that the Doxygen
comments for the same API are identical in both src/cpu_up.c and
src/cpu_mp.c . This ensures that Doxygen compilation does not
generate warnings, and the files are automatically merged into a
single file in the HTML document.
Signed-off-by: Chen Wang <[email protected]>
|
|
* [libcpu/arm64] add C11 atomic ticket spinlock
Replace the former implementation of flag-based spinlock which is unfair
Besides, C11 atomic implementation is more readable (it's C anyway),
and maintainable. Cause toolchain can use their builtin optimization and
tune for different micro-architectures. For example armv8.5 introduces a
better instruction. The compiler can help with that when it knows your
target platform in support of it.
Signed-off-by: Shell <[email protected]>
* fixup: RT_CPUS_NR
---------
Signed-off-by: Shell <[email protected]>
|
|
Signed-off-by: Shell <[email protected]>
|
|
* [src] add rt_hw_cpu_id() wrapper API
rt_hw_cpu_id() is an unsafe API which should not be used by most codes
directly. It's error-prone because it must be used in proper context,
otherwise it can lead to errors and unpredictable behavior.
This patch adds a wrapper API for rt_hw_cpu_id() to address this risk.
It includes the context-checking functionality and provides a safer
alternative for obtaining CPU IDs, ensuring that it is used correctly
within the appropriate context.
Signed-off-by: Shell <[email protected]>
* fixup UMP
* update API & comment
* ci: cpp_check
---------
Signed-off-by: Shell <[email protected]>
|
|
|
|
|