Replace mutexes with semaphores to protect the channels in conjunction with
a priority boost algorithm based on the observers' priority.
Signed-off-by: Rodrigo Peixoto <rodrigopex@gmail.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>
Add a name for the Kconfig choice symbol
indicating the Zbus subscriber buffer allocation
and adjust the name of the existing choices.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
Zbus uses mutexes internally that are available
only when MULTITHREADING is enabled so add
it to fix the following error:
/opt/zephyr-sdk-0.16.3/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/
12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: zephyr/subsys/
zbus/libsubsys__zbus.a(zbus.c.obj): in function `k_mutex_init':
/builds/zephyr/mcuboot/zephyr/include/generated/syscalls/kernel.h:969:
undefined reference to `z_impl_k_mutex_init'
Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com>
Besides the changed channel reference, the message subscribers receive a
copy of the message during the VDED execution. ZBus guarantees message
delivery for `MSG_SUBSCRIBERS`.
Signed-off-by: Rodrigo Peixoto <rodrigopex@gmail.com>
ZBus stores observers in two ways: statically using a list and dynamically
using a memory slab. Both present limitations. Static observers work only
for channel definition. The dynamic observers rely on a memory slab that
forces the user to manage its size to avoid issues with adding
observers. This commit fixes the static allocation problem by using the
iterable sections for allocating observation data and replacing the VDED
execution sequence since now it is possible to prioritize static observer
execution. All the runtime observers are dynamically allocated on the heap
instead of a specific memory pool.
BREAK changes (only internal, not APIs):
* ZBus channel metadata changed. Remove the observers' static array
pointer. Rename the `runtime_observers` pointer to `observers`. Add
`observer_start_idx` and `observer_end_idx`;
* Change the VDED execution sequence. The position (on definition time),
the priority in conjunction with the lexical order, is considered for
static post-definition time observers. At last, the runtime observer
follows the adding sequence;
* Replace the `CONFIG_ZBUS_RUNTIME_OBSERVERS_POOL_SIZE` with
`CONFIG_ZBUS_RUNTIME_OBSERVERS`.
New APIs:
* New iterable section iterators (for channels and observers) can now
receive a user_data pointer to keep context between the function calls;
* New `ZBUS_LISTENER_DEFINE_WITH_ENABLE(_name, _cb, _enable)` and
`ZBUS_SUBSCRIBER_DEFINE_WITH_ENABLE(_name, _queue_size, enable)` that
enable developers define disabled observers. They need to be enabled
during runtime to receive notifications from the bus;
* `ZBUS_CHAN_ADD_OBS` macro for adding post-definition static observers of
a channel.
Important changes:
* Move the ZBus LD file content to the `common-ram.ld` LD file. That was
necessary to make ZBus compatible with some Xtensa and RISCV boards.
Signed-off-by: Rodrigo Peixoto <rodrigopex@gmail.com>
Until now iterable sections APIs have been part of the toolchain
(common) headers. They are not strictly related to a toolchain, they
just rely on linker providing support for sections. Most files relied on
indirect includes to access the API, now, it is included as needed.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add zbus message bus as a Zephyr subsystem. No message bus
or communication abstraction other than the usual (message queues,
mailboxes, etc.) enabled developers to implement event-driven systems in
Zephyr quickly. Zbus would fill that gap by providing the community with
a lightweight and flexible message bus. The implementation tries to be
closest as possible to the existing ones. We use the claim/finish
approach, and the API for publishing and reading channels are similar
in message queues. Zbus is about channels, messages, and observers.
Signed-off-by: Rodrigo Peixoto <rodrigopex@gmail.com>
