This commit adds an additional test case for several kernel test suites
to ensure that the linker script generator is working correctly for a
subset of the Zephyr test suites.
The ensures that the basic functionality of the linker script generator
is working while still keep the performance impact on CI at a minimal
level.
Using the kernel tests is a trade-off between testing coverage of the
linker script generator and the time it takes to complete CI.
The kernel tests is considered to have the broadest coverage of various
features important for the generated linker script.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Move to CMake 3.20.0.
At the Toolchain WG it was decided to move to CMake 3.20.0.
The main reason for increasing CMake version is better toolchain
support.
Better toolchain support is added in the following CMake versions:
- armclang, CMake 3.15
- Intel oneAPI, CMake 3.20
- IAR, CMake 3.15 and 3.20
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
work_q.c is not being built or used, it was replaced by user_work.c
which now has k_work_user_queue_start.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Legacy k_work API has been marked deprecated, but it is still present
in tree and should be tested. Avoid CI warnings by disabling warnings
on use of deprecated API within the test source files.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The return value is documented to be true if the work was pending, but
the implementation returned true only if the work was actually running
(i.e. the caller had to wait). It should also return true if
scheduled or submitted work was cancelled.
Note that this means the return value cannot be used to determine
whether the call slept.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Shared data can't live on thread stacks if they are incoherent. These
are all just per-test-case data, so make them static.
Fixes#33898
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
k_work_schedule() is supposed to be a no-op if the work item is
already scheduled or submitted: the previous schedule is left
unchanged. The check incorrectly inhibited the schedule operation
when the work item was neither scheduled nor submitted, but was
running.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The original implementation of resubmitting a delayed work item
removed the item not only from the schedule, but also from the work
queue if it was already in the work queue. This is not the semantics
of the new implementation, which will leave the work item in the queue
if the previous deadline had elapsed and the work item was submitted.
The new semantics is preferred, as it improves consistency with SMP
targets where once an item has been submitted to a queue it can be run
at any time, and scheduling it again doesn't magically reverse the
submission. The original test would never have passed on an SMP
target, and passes now on qemu_x86 only because the timing granularity
prevents the work item from being both scheduled and queued at the
same time.
The problematic test application is the one developed for the original
implementation. Correct functioning of the new implementation is
fully verified by the sibling work test. That the legacy API does not
precisely preserve the original behavior where it was not consistent
between SMP and uniprocessor targets is regrettable, but unavoidable.
Remove the tests that cannot pass reliably.
Also fix a missing reset() after a test.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Putting IPC elements on the stack isn't allowed when KERNEL_COHERENCE
is set, just make test case data static (not all apps or subsystems
are going to work with incoherent stacks, but we should support it
where we can).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Now that the old API has been reimplemented with the new API remove
the old implementation and its tests.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The new API cannot be used from userspace because it is not merely a
wrapper around existing userspace-capable objects (threads and
queues), but instead requires much more complex and lower-level access
to memory that can't be touched from userspace. The vast majority of
work queue users are operating from privileged mode, so there's little
motivation to go through the pain and complexity of converting all
functions to system calls.
Copy the necessary pieces of the existing userspace work queue API out
and expose them with new names and types:
* k_work_handler_t becomes k_work_user_handler_t
* k_work becomes k_work_user
* k_work_q becomes k_work_user_q
etc. Because the replacement API cannot use the same types new API
names are also introduced to make it more clear that the userspace
work queue API is a separate functionality.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
When the kernel is TICKLESS, timeouts are set as needed, and drivers
all have some minimum amount of time before which they can reliably
schedule an interrupt. When this happens, drivers will kick the
requested interrupt out by one tick. This means that it's not
reliably possible to get a timeout set for "one tick in the
future"[1].
And attempting to do that is dangerous anyway. If the driver will
delay a one-tick interrupt, then code that repeatedly tries to
schedule an imminent interrupt may end up in a state where it is
constantly pushing the interrupt out into the future, and timer
interrupts stop arriving! The timeout layer actually has protection
against this case.
Finally getting to the point: in recent changes, the timeslice layer
lost its integration with the "imminent" test in the timeout code, so
it's now able to run into this situation: very rapidly context
switching code (or rapidly arriving interrupts) will have the effect
of infinitely[2] delaying timeouts and stalling the whole timeout
subsystem.
Don't try to be fancy. Just clamp timeslice duration such that a
slice is 2 ticks at minimum and we'll never hit the problem. Adjust
the two tests that were explicitly requesting very short slice rates.
[1] Of course, the tradeoff is that the tick rate can be 100x higher
or more, so on balance tickless is a huge win.
[2] Actually it only lasts until a 31 bit signed rollover in the HPET
cycle count in practice.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Set work item's flag in pending state, it cannot be append to a
workqueue. Improve branch coverage of function k_work_submit_to_queue().
Signed-off-by: Ying ming <mingx.ying@intel.com>
Adds a K_DELAYED_WORK_DEFINE, matching the K_WORK_DEFINE macro, with
accompanying Z_DELAYED_WORK_INITIALIZER macro.
Makes k_delayed_work_init a static inline function, like its K_WORK
counterpart.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
Nothing in the API description the delayed work structure sanctions
direct reference to internal fields. Do not assume that a delayed
work item can be initialized in any way other than by invoking the
delayed work item init function. Do not assume that a delayed work
item can be submitted without delay by invoking k_work_submit() with a
reference to the contained work item.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
These tests were suppressed when KERNEL_COHERENCE=y because of a
feature collision with CONFIG_POLL that has since been fixed.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
We can't control ticks accurately enough to detect the transition
between on a queue and being handled, so relax the checks to make
things pass.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The k_poll implementation places a struct _poller on the stack and
shares it with other threads, which is incompatible with the
KERNEL_COHERENCE model of cached stacks.
Make this a hard build failure instead of a kconfig dependency for
clarity. The failures if a user actually enables both are subtle and
difficult to debug.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Detection of transition from delayed to pending can fail in some cases
if the timeouts are not precisely managed.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The current implementation of delayed work will cancel and re-submit a
pending work item that is no-wait, putting it at the back of the
queue. Verify this behavior.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The current implementation of delayed work retains a pointer to the
queue unless the work item is successfully cancelled, preventing a
completed item from being resubmitted to a different queue. Confirm
this behavior and its workaround.
Also validates some unsuccessful cancel return values.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Pass a pointer to the work item member rather than casting the
augmented work item pointer to a base work item pointer.
Also the return type of k_work_pending() is bool, so use that rather
than comparing it to zero.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The test_triggered_wait_expired test submits the items with
2*SUBMIT_WAIT timeout and waits for the timeout to expire
so the items are being worked on. It waits one SUBMIT_WAIT
and checks none of the items have started. Then waits
another SUBMIT_WAIT to check if they have all finished.
However, since the timeout is at 2*SUBMIT_WAIT, the work
queue may have just started going through the list of items.
This means some items may have started while others have not.
This results in the test failing as not all items have
finished. So lengthen the second sleep to allow items to
finish before checking.
Fixes#28589
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Add k_delayed_work_pending similar to k_work_pending to check if the
delayed work item has been submitted but not yet completed.
This would compliment the API since using k_work_pending or
k_delayed_work_remaining_get is not enough to check this condition.
This is because the timeout could have run out, but the timeout handler
not yet processed and put the work into the workqueue.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
During inspection of the workqueue tests, I find out testing gaps.
Decided to add new test cases that can improve Zephyr OS testing
quality.
Added new test cases:
1. test_work_item_supplied_with_func
In docs described that work item supplied with a handler function,
prove that it works.
2. test_process_work_items_fifo
Test that system process work items in first-in, first-out manner.
3. test_sched_delayed_work_item
Verify that delayed work item processed after specific period of time
stated by user.
4. test_workqueue_max_number
Test the limit of number of workqueues created
5. test_cancel_processed_work_item Created test to increase branch
coverage.
Modified existing test cases:
1. test_work_submit_handler updated Doxygen tag, added more detailed
description"
Signed-off-by: Maksim Masalski <maksim.masalski@intel.com>
The k_queue data structure, when CONFIG_POLL was enabled, would
inexplicably use k_poll() as its blocking mechanism instead of the
original wait_q/pend() code. This was actually racy, see commit
b173e4353f. The code was structured as a condition variable: using
a spinlock around the queue data before deciding to block. But unlike
pend_current_thread(), k_poll() cannot atomically release a lock.
A workaround had been in place for this, and then accidentally
reverted (both by me!) because the code looked "wrong".
This is just fragile, there's no reason to have two implementations of
k_queue_get(). Remove.
Note that this also removes a test case in the work_queue test where
(when CONFIG_POLL was enabled, but not otherwise) it was checking for
the ability to immediately cancel a delayed work item that was
submitted with a timeout of K_NO_WAIT (i.e. "queue it immediately").
This DOES NOT work with the origina/non-poll queue backend, and has
never been a documented behavior of k_delayed_work_submit_to_queue()
under any circumstances. I don't know why we were testing this.
Fixes#25904
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
... because it is (required).
This makes a difference when building with CMake and forgetting
ZEPHYR_BASE or not registering Zephyr in the CMake package registry.
In this particular case, REQUIRED turns this harmless looking log
statement:
-- Could NOT find Zephyr (missing: Zephyr_DIR)
-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
-- Check for working C compiler: /usr/bin/cc
-- ...
-- ...
-- ...
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:8 (target_sources):
Cannot specify sources for target "app" which is not built by
this project.
... into this louder, clearer, faster and (last but not least) final
error:
CMake Error at CMakeLists.txt:5 (find_package):
Could not find a package configuration file provided by "Zephyr" with
any of the following names:
ZephyrConfig.cmake
zephyr-config.cmake
Add the installation prefix of "Zephyr" to CMAKE_PREFIX_PATH or set
"Zephyr_DIR" to a directory containing one of the above files. If
"Zephyr" provides a separate development package or SDK, be sure it
has been installed.
-- Configuring incomplete, errors occurred!
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
In Qemu icount mode, busy wait will cause lots of wall time and it's
very easy to get sanitycheck timeout(this case will be successful if
given enough timeout value for sanitycheck), so reduce test interval
to save execution time.
Signed-off-by: Wentong Wu <wentong.wu@intel.com>
Pun all workqueue tests under 1 doxygen group.
This removes kernel_workqueue_triggered_tests and
kernel_workqueue_delayed_tests doxygen groups.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add a k_timeout_t type, and use it everywhere that kernel API
functions were accepting a millisecond timeout argument. Instead of
forcing milliseconds everywhere (which are often not integrally
representable as system ticks), do the conversion to ticks at the
point where the timeout is created. This avoids an extra unit
conversion in some application code, and allows us to express the
timeout in units other than milliseconds to achieve greater precision.
The existing K_MSEC() et. al. macros now return initializers for a
k_timeout_t.
The K_NO_WAIT and K_FOREVER constants have now become k_timeout_t
values, which means they cannot be operated on as integers.
Applications which have their own APIs that need to inspect these
vs. user-provided timeouts can now use a K_TIMEOUT_EQ() predicate to
test for equality.
Timer drivers, which receive an integer tick count in ther
z_clock_set_timeout() functions, now use the integer-valued
K_TICKS_FOREVER constant instead of K_FOREVER.
For the initial release, to preserve source compatibility, a
CONFIG_LEGACY_TIMEOUT_API kconfig is provided. When true, the
k_timeout_t will remain a compatible 32 bit value that will work with
any legacy Zephyr application.
Some subsystems present timeout (or timeout-like) values to their own
users as APIs that would re-use the kernel's own constants and
conventions. These will require some minor design work to adapt to
the new scheme (in most cases just using k_timeout_t directly in their
own API), and they have not been changed in this patch, instead
selecting CONFIG_LEGACY_TIMEOUT_API via kconfig. These subsystems
include: CAN Bus, the Microbit display driver, I2S, LoRa modem
drivers, the UART Async API, Video hardware drivers, the console
subsystem, and the network buffer abstraction.
k_sleep() now takes a k_timeout_t argument, with a k_msleep() variant
provided that works identically to the original API.
Most of the changes here are just type/configuration management and
documentation, but there are logic changes in mempool, where a loop
that used a timeout numerically has been reworked using a new
z_timeout_end_calc() predicate. Also in queue.c, a (when POLL was
enabled) a similar loop was needlessly used to try to retry the
k_poll() call after a spurious failure. But k_poll() does not fail
spuriously, so the loop was removed.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Kernel timeouts have always been a 32 bit integer despite the
existence of generation macros, and existing code has been
inconsistent about using them. Upcoming commits are going to make the
timeout arguments opaque, so fix things up to be rigorously correct.
Changes include:
+ Adding a K_TIMEOUT_EQ() macro for code that needs to compare timeout
values for equality (e.g. with K_FOREVER or K_NO_WAIT).
+ Adding a k_msleep() synonym for k_sleep() which can continue to take
integral arguments as k_sleep() moves away to timeout arguments.
+ Pervasively using the K_MSEC(), K_SECONDS(), et. al. macros to
generate timeout arguments.
+ Removing the usage of K_NO_WAIT as the final argument to
K_THREAD_DEFINE(). This is just a count of milliseconds and we need
to use a zero.
This patch include no logic changes and should not affect generated
code at all.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Using find_package to locate Zephyr.
Old behavior was to use $ENV{ZEPHYR_BASE} for inclusion of boiler plate
code.
Whenever an automatic run of CMake happend by the build system / IDE
then it was required that ZEPHYR_BASE was defined.
Using ZEPHYR_BASE only to locate the Zephyr package allows CMake to
cache the base variable and thus allowing subsequent invocation even
if ZEPHYR_BASE is not set in the environment.
It also removes the risk of strange build results if a user switchs
between different Zephyr based project folders and forgetting to reset
ZEPHYR_BASE before running ninja / make.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This makes the tests actually assert if k_delayed_work_submit fails to
resubmit to ensure that not only the work is executed but also no errors
are reported in such case.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
