79e6b0e0f6
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>. This patch proposes to then include <zephyr/kernel.h> instead of <zephyr/zephyr.h> since it is more clear that you are including the Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a catch-all header that may be confusing. Most applications need to include a bunch of other things to compile, e.g. driver headers or subsystem headers like BT, logging, etc. The idea of a catch-all header in Zephyr is probably not feasible anyway. Reason is that Zephyr is not a library, like it could be for example `libpython`. Zephyr provides many utilities nowadays: a kernel, drivers, subsystems, etc and things will likely grow. A catch-all header would be massive, difficult to keep up-to-date. It is also likely that an application will only build a small subset. Note that subsystem-level headers may use a catch-all approach to make things easier, though. NOTE: This patch is **NOT** removing the header, just removing its usage in-tree. I'd advocate for its deprecation (add a #warning on it), but I understand many people will have concerns. Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no> |
||
|---|---|---|
| .. | ||
| src | ||
| CMakeLists.txt | ||
| Kconfig | ||
| README.txt | ||
| prj.conf | ||
| testcase.yaml | ||
README.txt
Title: Timer Starvation test The purpose of the test is to detect whether the timer implementation correctly handles situations where only one timeout is present, and that timeout is repeatedly rescheduled before it has a chance to fire. In some implementations this may prevent the timer interrupt handler from ever being invoked, which in turn prevents an announcement of ticks. Lack of tick announcement propagates into a monotonic increase in the value returned by sys_clock_elapsed(). This test is not run in automatic test suites because it generally takes minutes, hours, or days to fail, depending on the hardware clock rate and the tick rate. By default the test passes if one hour passes without detecting a failure. Failure will occur when some counter wraps around. This may be a hardware timer counter, a timer driver internal calculation of unannounced cycles, or the Zephyr measurement of unannounced ticks. For example a system that uses a 32768-Hz internal timer counter with 24-bit resolution and determines elapsed time by a 24-bit unsigned difference between the current and last-recorded counter value will fail at 512 s when the updated counter value is observed to be less than the last recorded counter. Systems that use a 32-bit counter of 80 MHz ticks would fail after 53.687 s.