For posix layer implementation of message queue, we need to fetch
basic attributes of message queue. Currently this routine is not
present in Zephyr. So adding this routing into message queue.
Signed-off-by: Youvedeep Singh <youvedeep.singh@intel.com>
The k_mem_partition structs need to be placed in the kernel memory.
This patch ensures that these structs are placed correctly.
Also when a struct k_mem_domain is declared it is advised to add
__kernel.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
During system initialization, the global static variable (to
mem_domain.c) is initialized with the number of maximum partitions per
domain. This variable is of u8_t type.
Assertions throughout the code will check ranges and test for overflow
by relying on implicit type conversion.
Use an u8_t instead of u32_t to avoid doubts. Also, reorder the
k_mem_partition struct to remove the alignment hole created by reducing
sizeof(num_partitions).
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
The scheduler needs a few tweaks to work in SMP mode:
1. The "cache" field just doesn't work. With more than one CPU,
caching the highest priority thread isn't useful as you may need N
of them at any given time before another thread is returned to the
scheduler. You could recalculate it at every change, but that
provides no performance benefit. Remove.
2. The "bitmask" designed to prevent the need to individually check
priorities is likewise dropped. This could work, but in fact on
our only current SMP system and with current K_NUM_PRIOPRITIES
values it provides no real benefit.
3. The individual threads now have a "current cpu" and "active" flag
so that the choice of the next thread to run can correctly skip
threads that are active on other CPUs.
The upshot is that a decent amount of code gets #if'd out, and the new
SMP implementations for _get_highest_ready_prio() and
_get_next_ready_thread() are simpler and smaller, at the expense of
having to drop older optimizations.
Note that scheduler synchronization is unchanged: all scheduler APIs
used to require that an irq_lock() be held, which means that they now
require the global spinlock via the same API. This should be a very
early candidate for lock granularity attention!
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This is a mostly-internal API to start a secondary system CPU, with an
implementation for the ESP-32 "APP" cpu. Exposed in kernel.h because
it's plausibly useful for asymmetric MP code managed by an app.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The existing __swap() mechanism is too high level for some
applications because of its scheduler-awareness. This introduces a
new _arch_switch() mechanism, which is a simpler primitive that looks
like:
void _arch_switch(void *handle, void **old_handle_out);
The new thread handle (typically just a stack pointer) is specified
explicitly instead of being picked up from the scheduler by
per-architecture code, and on return the "old" thread handle that got
switched out is returned through the pointer.
The new primitive (currently available only on xtensa) is selected
when CONFIG_USE_SWITCH is "y". A new C _Swap() implementation based
on this primitive is then added which operates compatibly.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
As discovered in https://github.com/zephyrproject-rtos/zephyr/issues/5952
...a duplicate call to k_delayed_work_submit_to_queue() on a work item
whose timeout had expired but which had not yet executed (i.e. it was
pending in the queue for the active work queue thread) would fail,
because the cancellation step wouldn't clear the PENDING bit, causing
the resubmission to see the object in an invalid state. Trivially
fixed by adding a bit clear.
It also turns out that the behavior of the code doesn't match the
docs, which state that a PENDING work item is not supposed to be
cancelled at all. Fix the docs to remove that.
And on yet further review, it turns out that there's no way to make a
test like the one in the linked bug threadsafe. The work queue does
no synchronization by design, so if the user code does no external
synchronization it might very well clobber the running handler. Added
a sentence to the docs to reflect this gotcha.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
As per current policy of requiring supervisor mode to register
callbacks, dma_config() is omitted.
A note added about checking the channel ID for start/stop, current
implementations already do this but best make it explicitly
documented.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The k_mem_pool_free API has no use for the full k_mem_block struct. In
particular, it only needs the k_mem_block_id. Introduce a new API
which takes only this essential struct. This paves the way to
simplify & improve the k_malloc/k_free implementation a bit.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This was failing with compiler warnings. Looks like latest compilers
enable warnings by default that we do not have in the current SDK.
This was failing with unit tests being built natively.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Of these, only struct net_ipv6_nbr_data::send_ns is a descriptive
change:
send_ns is used for timing Neighbor Solicitations in general, not
just for DAD.
The rest are typo/grammar fixes.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
We have removed this features when we moved to the unified kernel. Those
functions existed to support migration from the old kernel and can go
now.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Remove references to k_mem_pool_defrag and any related bits associated
with mem_pool defrag that don't make sense anymore.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
In case K_POLL_STATE_NOT_READY is set the return will be set to -EINTR
indicating that the poll was interrupted.
Fixes#5026
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The new mem pool implementation has a hard minimum block size of 8
bytes, but the macros to statically compute the number of levels
didn't clamp, leading to invalid small allocations being allowed,
which would then corrupt the list pointers of nearby blocks and/or
overflow the buffer entirely and corrupt other memory.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Added architecture specific support for memory domain destroy
and remove partition for arm and nxp. An optimized version of
remove partition was also added.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
Kernel object metadata had an extra data field added recently to
store bounds for stack objects. Use this data field to assign
IDs to thread objects at build time. This has numerous advantages:
* Threads can be granted permissions on kernel objects before the
thread is initialized. Previously, it was necessary to call
k_thread_create() with a K_FOREVER delay, assign permissions, then
start the thread. Permissions are still completely cleared when
a thread exits.
* No need for runtime logic to manage thread IDs
* Build error if CONFIG_MAX_THREAD_BYTES is set too low
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We need to start enforcing everywhere that kernel.h depends on
arch/cpu.h and any header included in the arch/cpu.h space cannot
depend on kernel.h.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This should clear up some of the confusion with random number
generators and drivers that obtain entropy from the hardware. Also,
many hardware number generators have limited bandwidth, so it's natural
for their output to be only used for seeding a random number generator.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Some "random" drivers are not drivers at all: they just implement the
function `sys_rand32_get()`. Move those to a random subsystem in
preparation for a reorganization.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Use-cases for these subsystems appear to be limited to board/SOC
code, network stacks, or other drivers, no need to expose to
userspace at this time. If we change our minds it's easy enough
to add them back.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
_POLL_NUM_TYPES & _POLL_NUM_STATES are values of an enum, which the
preprocessor does not know about.
But the first of the removed lines needs to be evaluated by the
preprocessor using them.
The result is that the preprocessor will treat _POLL_NUM_TYPES
and _POLL_NUM_STATES as 0 in that expression, which would not seem the
intended behavior. It will also produce 2 warnings about this in each
file which includes kernel.h (lots)
=> lines 3779-3781 are be removed.
--------- The compiler warning:
include/kernel.h:3774:11: warning: "_POLL_NUM_TYPES" is not defined [-W
+ _POLL_NUM_TYPES \
^
include/kernel.h:3779:5: note: in expansion of macro ?_POLL_EVENT_NUM_U
^
include/kernel.h:3775:11: warning: "_POLL_NUM_STATES" is not defined [-
+ _POLL_NUM_STATES \
^
include/kernel.h:3779:5: note: in expansion of macro ?_POLL_EVENT_NUM_U
^
--------
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
This is a runtime counterpart to K_THREAD_ACCESS_GRANT().
This function takes a thread and a NULL-terminated list of kernel
objects and runs k_object_access_grant() on each of them.
This function doesn't require any special permissions and doesn't
need to become a system call.
__attribute__((sentinel)) added to warn users if they omit the
required NULL termination.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
It's possible to declare static threads that start up as K_USER,
but these threads can't do much since they start with permissions on
no kernel objects other than their own thread object.
Rather than do some run-time synchronization to have some other thread
grant the necessary permissions, we introduce macros
to conveniently assign object permissions to these threads when they
are brought up at boot by the kernel. The tables generated here
are constant and live in ROM when possible.
Example usage:
K_THREAD_DEFINE(my_thread, STACK_SIZE, my_thread_entry,
NULL, NULL, NULL, 0, K_USER, K_NO_WAIT);
K_THREAD_ACCESS_GRANT(my_thread, &my_sem, &my_mutex, &my_pipe);
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Currently this is defined as a k_thread_stack_t pointer.
However this isn't correct, stacks are defined as arrays. Extern
references to k_thread_stack_t doesn't work properly as the compiler
treats it as a pointer to the stack array and not the array itself.
Declaring as an unsized array of k_thread_stack_t doesn't work
well either. The least amount of confusion is to leave out the
pointer/array status completely, use pointers for function prototypes,
and define K_THREAD_STACK_EXTERN() to properly create an extern
reference.
The definitions for all functions and struct that use
k_thread_stack_t need to be updated, but code that uses them should
be unchanged.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
User threads can only create other nonessential user threads
of equal or lower priority and must have access to the entire
stack area.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We need to track permission on stack memory regions like we do
with other kernel objects. We want stacks to live in a memory
area that is outside the scope of memory domain permission
management. We need to be able track what stacks are in use,
and what stacks may be used by user threads trying to call
k_thread_create().
Some special handling is needed because thread stacks appear as
variously-sized arrays of struct _k_thread_stack_element which is
just a char. We need the entire array to be considered an object,
but also properly handle arrays of stacks.
Validation of stacks also requires that the bounds of the stack
are not exceeded. Various approaches were considered. Storing
the size in some header region of the stack itself would not allow
the stack to live in 'noinit'. Having a stack object be a data
structure that points to the stack buffer would confound our
current APIs for declaring stacks as arrays or struct members.
In the end, the struct _k_object was extended to store this size.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This is too powerful for user mode, the other access APIs
require explicit permissions on the threads that are being
granted access.
The API is no longer exposed as a system call and hence will
only be usable by supervisor threads.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
It's currently too easy to run out of thread IDs as they
are never re-used on thread exit.
Now the kernel maintains a bitfield of in-use thread IDs,
updated on thread creation and termination. When a thread
exits, the permission bitfield for all kernel objects is
updated to revoke access for that retired thread ID, so that
a new thread re-using that ID will not gain access to objects
that it should not have.
Because of these runtime updates, setting the permission
bitmap for an object to all ones for a "public" object doesn't
work properly any more; a flag is now set for this instead.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Fixes issues where these were getting sign-extended when
dumped out, resulting in (for example) "ffffffff" being
printed when it ought to be "ff".
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Does the opposite of k_object_access_grant(); the provided thread will
lose access to that kernel object.
If invoked from userspace the caller must hace sufficient access
to that object and permission on the thread being revoked access.
Fix documentation for k_object_access_grant() API to reflect that
permission on the thread parameter is needed as well.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
By default, threads are created only having access to their own thread
object and nothing else. This new flag to k_thread_create() gives the
thread access to all objects that the parent had at the time it was
created, with the exception of the parent thread itself.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
- Dumping error messages split from _k_object_validate(), to avoid spam
in test cases that are expected to have failure result.
- _k_object_find() prototype moved to syscall_handler.h
- Clean up k_object_access() implementation to avoid double object
lookup and use single validation function
- Added comments, minor whitespace changes
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This API only gets used inside system call handlers and a specific test
case dedicated to it. Move definition to the private kernel header along
with the rest of the defines for system call handlers.
A non-userspace inline variant of this function is unnecessary and has
been deleted.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
To avoid making a system call for every character emitted, there is now
a small line buffer if userspace is enabled. The interface to the kernel
is a new system call which takes a sized buffer of console data.
If userspace is not enabled this works like before.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
These are removed as the APIs that use them are not suitable for
exporting to userspace.
- Kernel workqueues run in supervisor mode, so it would not be
appropriate to allow user threads to submit work to them. A future
enhancement may extend or introduce parallel API where the workqueue
threads may run in user mode (or leave as an exercise to the user).
- Kernel slabs store private bookkeeping data inside the
user-accessible slab buffers themselves. Alternate APIs are planned
here for managing slabs of kernel objects, implemented within the
runtime library and not the kernel.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
k_pipe_block_put() will be done in another patch, we need to design
handling for the k_mem_block object.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
