The poll code was playing this weird trick where the thread pointer in
the "struct _poller" object for a triggered work item. It would not
be a thread to wake up, but instead a pointer to the (non-polling)
thread operated by the work queue being triggered. The code would
never touch this thread, just use it as a way to get a pointer to the
enclosing work queue struct.
Just store the work queue pointer in the first place. It's much
simpler, and makes future modifications to remove that thread pointer
possible.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The triggered work scheme uses a trick where it overloads the thread
pointer field of the struct poller (which normally stores the ID of
the thread that is blocked in k_poll()) to be able to find the work
queue to which it will submit.
Give it its own pointer field to break this false dependency.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Somewhat weirdly, k_poll() can do one of two things when the set of
events is signaled: it can wake up a sleeping thread, or it can submit
an unrelated work item to a work queue. The difference in behaviors
is currently captured by a callback, but as there are only two it's
cleaner to put this into a "mode" enumerant. That also shrinks the
size of the data such that the poller struct can be moved somewhere
other than the calling stack.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This enables storing errno in the thread local storage area.
With this enabled, a syscall to access errno can be avoided
when userspace is also enabled.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This adds the common struct fields and functions to support
the implementation of thread local storage in individual
architecture. This uses the thread stack to store TLS data.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For compatibility layers like CMSIS where thread objects
are drawn from a pool, provide a context pointer to the
exited thread object so it may be freed.
This is somewhat obscure and has no supporting APIs or
overview documentation and should be considered a private
kernel feature. Applications should really be using
k_thread_join() instead.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The delayed work API has been changed to allow cancellation in
conditions not previously documented, but this feature can cause both
submission and cancellation to fail in the general case. Summarize
the conditions and highlight the importance of checking result codes
for these functions.
Also explicitly note that no kernel API can reliably indicate that a
work item has been completed, and that doing so is the responsibility
of the code that provides the work handler.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Although the documentation states that only work items that have not
completed the delay can be cancelled, in fact pending items can also
be removed from a work queue. Document that behavior
Also document the specific return value that will be obtained based on
the state of the work item at the time cancellation was attempted
using the current implementation.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The delayed work work_q pointer is set on submission, and remains set
even after the work item completes. Attempts to re-submit the
completed work item to a different queue will be rejected because the
code cannot distinguish a completed item from one that is still
waiting for a delay or to be processed.
Document this restriction.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Make more clear that submitting a work item to one queue while it is
pending on another queue has no effect.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
k_queue uses a sflist.
The macro used for initialising the list is the slist not sflist macro.
This commit just changes the macro to use the sflist init macro.
Fixes#28912
Signed-off-by: Toby Firth <tobyjfirth@gmail.com>
Remove old K_ prefixed macros defined in kernel.h as well as the
following APIs:
k_uptime_delta_32
k_enable_sys_clock_always_on
k_disable_sys_clock_always_on
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The documentation of the callback implies it is invoked from a thread,
but the documentation of the stop function states it can be called
from interrupt context.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
API that takes k_timer structures but doesn't change data in them is
updated to const-qualify the underlying object, allowing information
to be retrieved from contexts where the containing object is
immutable.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
API that takes _timeout structures but doesn't change data in them is
updated to const-qualify the underlying object, allowing information
to be retrieved from contexts where the containing object is
immutable.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Both operands of an operator in the arithmetic conversions
performed shall have the same essential type category.
Changes are related to converting the integer constants to the
unsigned integer constants
Signed-off-by: Aastha Grover <aastha.grover@intel.com>
The generic kernel API did not specify the effect of the call on the
interrupt lockout state. The implementation forwards to
arch_cpu_atomic_idle() which does document that the state is restored
to the state specified in the passed key, which makes it have the
effect of invoking irq_unlock(key).
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
k_thread_create() works as expected on both uninitialized memory,
or threads that have completely exited.
However, horrible and difficult to comprehend things can happen if a
thread object is already being used by the kernel and
k_thread_create() is called on it.
Historically this has been a problem with test cases trying to be
parsimonious with thread objects and not properly cleaning up
after themselves. Add an assertion for this which should catch
both the illegal creation of a thread already active, or threads
racing to create the same thread object.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Amend Doxygen documentation for k_msgq_put to note that the message
content will not be modified as a result of the function call and
constify data parameter in function prototype.
Fixes#22301
Signed-off-by: Lauren Murphy <lauren.murphy@intel.com>
Added a note in documentation for k_mem_slab_alloc(),
k_mem_pool_alloc() and k_heap_alloc() are safe
to call in an interrupt with the timeout K_NO_WAIT.
Fixes: #28020
Signed-off-by: Spoorthy Priya Yerabolu <spoorthy.priya.yerabolu@intel.com>
This updates Kconfig options in the Doxygen documentation to use the new
@option ALIAS. There are three categories of fixes:
* Use of `:option:` inside Doxygen headers, which is not valid (this is
rST syntax!).
* Kconfig options that were just written as plain text and were no
references were generated.
* Use of `@rst` blocks where the only reason for using them was to have
Kconfig options resolved.
Signed-off-by: Fabio Utzig <fabio.utzig@nordicsemi.no>
The k_object API associates mutable state structures with known kernel
objects to support userspace. The kernel objects themselves are not
modified by the API, and in some cases (e.g. device structures) may be
const-qualified. Update the API so that pointers to these const
kernel objects can be passed without casting away the const qualifier.
Fixes#27399
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Following are the changes to variable names that are matching
with tag names (Rule 5.7 violations)
In kernel.h, event_type is matching with a tag name in
lib/os/onoff.c. Added a _ prefix to event_type and
also to the macro argument names.
In userspace.c, *dyn_obj is matching with the tag name
dyn_obj in the file itslef. Changed it to dyn
In device.h, device_mmio.h, init.h and init.c,
changed the *device to dev. Except for one change in
init.h
Signed-off-by: Spoorthy Priya Yerabolu <spoorthy.priya.yerabolu@intel.com>
This now has its own header instead of kernel.h. The code is
unchanged other than a forward declaration of k_tid_t.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Add note regarding safe use of the k_work_pending return value. Similar
to the note for k_delayed_work_pending.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
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>
These stacks are appropriate for threads that run purely in
supervisor mode, and also as stacks for interrupt and exception
handling.
Two new arch defines are introduced:
- ARCH_KERNEL_STACK_GUARD_SIZE
- ARCH_KERNEL_STACK_OBJ_ALIGN
New public declaration macros:
- K_KERNEL_STACK_RESERVED
- K_KERNEL_STACK_EXTERN
- K_KERNEL_STACK_DEFINE
- K_KERNEL_STACK_ARRAY_DEFINE
- K_KERNEL_STACK_MEMBER
- K_KERNEL_STACK_SIZEOF
If user mode is not enabled, K_KERNEL_STACK_* and K_THREAD_STACK_*
are equivalent.
Separately generated privilege elevation stacks are now declared
like kernel stacks, removing the need for K_PRIVILEGE_STACK_ALIGN.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Thread objects were moved out of the stack a long time ago.
Replacing this incorrect information is some clarification
on acceptable size values to pass in.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The core kernel computes the initial stack pointer
for a thread, properly aligning it and subtracting out
any random offsets or thread-local storage areas.
arch_new_thread() no longer needs to make any calculations,
an initial stack frame may be placed at the bounds of
the new 'stack_ptr' parameter passed in. This parameter
replaces 'stack_size'.
thread->stack_info is now set before arch_new_thread()
is invoked, z_new_thread_init() has been removed.
The values populated may need to be adjusted on arches
which carve-out MPU guard space from the actual stack
buffer.
thread->stack_info now has a new member 'delta' which
indicates any offset applied for TLS or random offset.
It's used so the calculations don't need to be repeated
if the thread later drops to user mode.
CONFIG_INIT_STACKS logic is now performed inside
z_setup_new_thread(), before arch_new_thread() is called.
thread->stack_info is now defined as the canonical
user-accessible area within the stack object, including
random offsets and TLS. It will never include any
carved-out memory for MPU guards and must be updated at
runtime if guards are removed.
Available stack space is now optimized. Some arches may
need to significantly round up the buffer size to account
for page-level granularity or MPU power-of-two requirements.
This space is now accounted for and used by virtue of
the Z_THREAD_STACK_SIZE_ADJUST() call in z_setup_new_thread.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Fixing issues with recent versions of breathe 4.19.2:
WARNING: Unparseable C cross-reference: 'struct device'
Invalid C declaration: Expected identifier in nested name, got keyword:
struct [error at 6]
struct device
------^
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Recent changes to struct _timeout changed the declaration order to
avoid alignment padding. While this has no effect to C99 code C++
requires that designated initializes appear in declaration order.
Update the initializer macro so it can be used in C++ code.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The functions k_work_poll_submit_to_queue(), k_work_poll_submit() and
k_poll() described the parameter events as an "array of pointers to
events" which is not accurate. Replaced the description with "array of
events".
This fixes#23775
Signed-off-by: Christian Taedcke <christian.taedcke@lemonbeat.com>
For iterable areas defined with Z_STRUCT_SECTION_ITERABLE(),
the corresponding output section in the linker script is just
boilerplate. Add macros to make these definitions simpler.
Unfortunately, we have a fair number of iterable sections not
defined with Z_STRUCT_SECTION_ITERABLE(), this patch does not
address this.
The output sections are all named <struct name>_area, update
sanitylib.py with this.
sys_sem with no userspace, and k_lifo/k_fifo are special cases
where different data types that are all equivalent need to be
put in the same iterable area. Add
Z_STRUCT_SECTION_ITERABLE_ALTERNATE() for this special case.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Added separator (e.g. comma or semicolon) parameter to FOR_EACH_ family.
Separator is added between macro execution for each argument and not at
the end.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
We now have a low-level function z_dynamic_object_create()
which is not a system call and is used for installing
kernel objects that are not supported by k_object_alloc().
Checking for valid object type enumeration values moved
completely to the implementation function.
A few debug messages and comments were improved.
Futexes and sys_mutexes are now properly excluded from
dynamic generation.
Signed-off-by: Andrew Boie <andrew.p.boie@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>
Mutex operations check ownership against _current. But in an
ISR, _current is just whatever thread was interrupted when the
ISR fired. Explicitly do not allow this.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Some tests assumed that a delay with k_busy_wait() could be precisely
timed by a tick or cycle count, and vice versa. This is not true for
all clock configurations on all Zephyr targets, so highlight the
potential variation.
As an example: on some platforms busy-wait is performed by a loop with
known duration in cycles of a known CPU frequency. The CPU clock may
be unrelated to the clock that drives the system timer.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
This commit renames the Kconfig `FP_SHARING` symbol to `FPU_SHARING`,
since this symbol specifically refers to the hardware FPU sharing
support by means of FPU context preservation, and the "FP" prefix is
not fully descriptive of that; leaving room for ambiguity.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
These helper functions may clarify how much data is available to read
from or write to the circular buffer of a k_pipe.
Fixes#25036
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
The k_thread_resource_pool_assign() parameters were incorrectly
documented. Part of the thread parameter description should have been
in memory pool variable documentation.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Use of the K_POLL_EVENT initializers in C++20 code causes a diagnostic
since C++ requires consistent use of designated initializers. As the
initialized object is an anonymous union there is no member name to
use, but neither is one required. Initialize the member without
wrapping it in braces as with an initializer list.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>