Use underlying Zephyr thread directly to store thread name instead of
storing the name in CMSIS control block. Also, allow `osThreadGetName`
to work within ISR, as expected from spec.
Signed-off-by: Utsav Munendra <utsavm@meta.com>
The osFlagsWaitAny option is not handled correctly. It returns once any
flag at all is set, whereas it is supposed to only return once one of
the flags specified in flags is set.
Signed-off-by: Utsav Munendra <utsavm@meta.com>
Clarify that all max limit on RTOS objects set by Kconfig only apply
to objects whose control blocks were dynamically allocated. The
CMSIS-RTOSv2 impl layer itself does not restrict the number of
statically created RTOS objects.
Signed-off-by: Utsav Munendra <utsavm@meta.com>
Clarify thread Kconfigs to denote the maximum number of dynamically
allocated control blocks and stacks for threads. Allow application to
create any number of threads with statically allocated control block
and stack.
Signed-off-by: Utsav Munendra <utsavm@meta.com>
Bugfix previous `osThreadJoin()` implementation where a thread which
exited with `osThreadExit()` could not be joined upon by other threads.
Signed-off-by: Utsav Munendra <utsavm@meta.com>
Do not use memory slabs for the control blocks when
the application provides the memory for it. This
implements manual user-defined allocation memory
management support in CMSIS-RTOSv2 API.
Signed-off-by: Utsav Munendra <utsavm@meta.com>
No functionality change, in preparation for allowing
threads with user provided stack and control block.
Signed-off-by: Utsav Munendra <utsavm@meta.com>
This enables the cmsis wrapper types to be declared
statically and then passed along to CMSIS-RTOSv2 APIs,
enabling static allocation of RTOS control blocks
in the subsequent commits.
Signed-off-by: Utsav Munendra <utsavm@meta.com>
Mostly a revert of commit b1def7145f ("arch: deprecate `_current`").
This commit was part of PR #80716 whose initial purpose was about providing
an architecture specific optimization for _current. The actual deprecation
was sneaked in later on without proper discussion.
The Zephyr core always used _current before and that was fine. It is quite
prevalent as well and the alternative is proving rather verbose.
Furthermore, as a concept, the "current thread" is not something that is
necessarily architecture specific. Therefore the primary abstraction
should not carry the arch_ prefix.
Hence this revert.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
At the present time, Zephyr does has overlap between sleeping and
suspending. Not only should sleeping and suspended be orthogonal
states, but we should ensure users always employ the correct API.
For example, to wake a sleeping thread, k_wakeup() should be used,
and to resume a suspended thread, k_thread_resume() should be used.
However, at the present time k_thread_resume() can be used on a
thread that called k_sleep(K_FOREVER). Sleeping should have nothing
to do with suspension.
This commit introduces the new _THREAD_SLEEPING thread state along
with some prep-work to facilitate the decoupling of the sleeping and
suspended thread states.
Signed-off-by: Peter Mitsis <peter.mitsis@intel.com>
Traditionally threads have been initialized with a PRESTART flag set,
which gets cleared when the thread runs for the first time via either
its timeout or the k_thread_start() API.
But if you think about it, this is no different, semantically, than
SUSPENDED: the thread is prevented from running until the flag is
cleared.
So unify the two. Start threads in the SUSPENDED state, point
everyone looking at the PRESTART bit to the SUSPENDED flag, and make
k_thread_start() be a synonym for k_thread_resume().
There is some mild code size savings from the eliminated duplication,
but the real win here is that we make space in the thread flags byte,
which had run out.
Signed-off-by: Andy Ross <andyross@google.com>
`_current` is now functionally equals to `arch_curr_thread()`, remove
its usage in-tree and deprecate it instead of removing it outright,
as it has been with us since forever.
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
These macros tend to be defined by too many headers.
Let's guard these definition with ifdefs to avoid
redefining them to practically the same.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
This extends the thread abort hook to support memory mapped
stack. The calculation to find out to which instance of thread
pools the outgoing thread belongs requires physical address.
So find the physical address via the memory mapped stack for
that.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
We shouldn't be calling hooks from optional and upper layer subsystems
in the kernel, instead, just call the hook to set thread status in the
API where it is needed.
This now clears related bit in cmsis thread status bitarray when
terminating a thread in the cmsis rtos v1 layer directly and not in the
kenrel code.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
There are several subsystems and boards which require a relatively large
system heap (used by k_malloc()) to function properly. This became even
more notable with the recent introduction of the ACPICA library, which
causes ACPI-using boards to require a system heap of up to several
megabytes in size.
Until now, subsystems and boards have tried to solve this by having
Kconfig overlays which modify the default value of HEAP_MEM_POOL_SIZE.
This works ok, except when applications start explicitly setting values
in their prj.conf files:
$ git grep CONFIG_HEAP_MEM_POOL_SIZE= tests samples|wc -l
157
The vast majority of values set by current sample or test applications
is much too small for subsystems like ACPI, which results in the
application not being able to run on such boards.
To solve this situation, we introduce support for subsystems to specify
their own custom system heap size requirement. Subsystems do
this by defining Kconfig options with the prefix HEAP_MEM_POOL_ADD_SIZE_.
The final value of the system heap is the sum of the custom
minimum requirements, or the value existing HEAP_MEM_POOL_SIZE option,
whichever is greater.
We also introduce a new HEAP_MEM_POOL_IGNORE_MIN Kconfig option which
applications can use to force a lower value than what subsystems have
specficied, however this behavior is disabled by default.
Whenever the minimum is greater than the requested value a CMake warning
will be issued in the build output.
This patch ends up modifying several places outside of kernel code,
since the presence of the system heap is no longer detected using a
non-zero CONFIG_HEAP_MEM_POOL_SIZE value, rather it's now detected using
a new K_HEAP_MEM_POOL_SIZE value that's evaluated at build.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When no heap has been configured, osMessageQueueNew() will no
longer include a call to k_calloc() (which needs the heap).
In such a configuration, if osMessageQueueNew() indicates that
the buffer must be allocated, it will fail and return NULL.
Fixes#61196
Signed-off-by: Peter Mitsis <peter.mitsis@intel.com>
Rearranges the k_mem_slab fields so that information that describes
how much of the memory slab is used is co-located. This will allow
easier of its statistics into the object core statistics reporting
framework.
Signed-off-by: Peter Mitsis <peter.mitsis@intel.com>
Modify the signature of the k_mem_slab_free() function with a new one,
replacing the old void **mem with void *mem as a parameter.
The following function:
void k_mem_slab_free(struct k_mem_slab *slab, void **mem);
has the wrong signature. mem is only used as a regular pointer, so there
is no need to use a double-pointer. The correct signature should be:
void k_mem_slab_free(struct k_mem_slab *slab, void *mem);
The issue with the current signature, although functional, is that it is
extremely confusing. I myself, a veteran Zephyr developer, was confused
by this parameter when looking at it recently.
All in-tree uses of the function have been adapted.
Fixes#61888.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
CONFIG_COVERAGE has been incorrectly used to
change other kconfig options (stack sizes, etc)
code defaults, as well as some samples behaviour,
which should not have dependend on it.
Instead those should have depended on COVERAGE_GCOV,
which, being the one which adds special code and
temporary RAM storage for embedded targets,
require changes to many features.
When building for the native targets, all this was
unnecessary.
=> Fix the dependency.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Instead of trusting blindly that k_mem_slab_init()
will succeed, let's check it, and handle failures
appropriately.
Otherwise, a buffer of garbage will be passed
around, leading to misterious failures later on.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
The cmsis implementations of osMutex was trying to inspect internal
k_mutex state (the owner and lock count) in the process of trying to
acquire the lock. This is unfixably racy, by definition other
contexts will be trying to do the same on the unsynchronized data.
As far as I can tell, the only purpose was to be able to synthesize
osMutex's specified error behavior, which we can do with the existing
return codes from k_mutex_lock(). Add similar logic to osSemaphore,
which didn't have the race but was likewise abusing access to kernel
internals.
Signed-off-by: Andy Ross <andyross@google.com>
NSEC_PER_MSEC should be defined along with the rest of the
per-sec macros in sys_clock.h. Currently, it's defined
multiply in a few separate locations.
Signed-off-by: Christopher Friedt <cfriedt@fb.com>
irq_lock() returns an unsigned integer key.
Generated by spatch using semantic patch
scripts/coccinelle/irq_lock.cocci
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
In order to bring consistency in-tree, migrate all subsystems code to
the new prefix <zephyr/...>. Note that the conversion has been scripted,
refer to zephyrproject-rtos#45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Move include paths and add new target_include_directories to support
backwards compatibility:
* /include -> /include/zephyr
example: <irq.h> -> <zephyr/irq.h>
Issue #41543
Signed-off-by: Yuval Peress <peress@google.com>
With the change of `atomic_t` from `int` to `long` there
were a few places where there was some type aliasing
occuring.
Update CMSIS to use `atomic_t` rather than `int` for all
atomic operations.
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
add a bitarray into struct osThreadDef_t to indicate whether the
thread is used or not, then we can get the first available thread
by searching this array when creating a new thread, and update this
array to add a free thread when terminating a thread.
Signed-off-by: Chen Peng1 <peng1.chen@intel.com>
we use flag 0 in osSignalWait function to wait for
any single signal flag, but with this 0 flag,
it won't clear thread signal results as expected,
we need to check whether signal flag is 0 firstly.
Signed-off-by: Chen Peng1 <peng1.chen@intel.com>
Move cmsis OS api headers under include/portability. Those are not
libraries and only serve to provide a level of abstraction using the
CMSIS OS APIs to existing Zephyr interfaces.
Removed one level and put them directly under include/portability.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Move cmsis OS apis under subsystem/portability. Those are not libraries
and only serve to provide a level of abstraction using the CMSIS OS APIs
to existing Zephyr interfaces.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
