Currently various zbus functions silently change the timeout
to zero when inside an ISR. If a developer is not aware
of this it could lead to unexpected behaviour or a
publish/read failing.
Also in the zbus docs it states to only use a timeout of
zero when inside a ISR multiple times.
Signed-off-by: Brandon Allen <brandon.allen@exacttechnology.com>
Add the option for a unique numeric identifiers to be attached to a
zbus channel. This identifier can then be used to lookup the channel
structure at runtime. This is useful in two situations (that I can
immediately think of).
Firstly for external interaction, i.e a text shell or remote procedure
calls. The current state of a channel can be queried by an ID that never
changes, as opposed to the external entity needing to know the exact
memory address of the channel for a given application binary.
Secondly for integrating with dynamically loaded extensions (llext).
These extensions can hook into the existing data streams without each
individual channel needing to be exported and visible to the loader.
Signed-off-by: Jordan Yates <jordan@embeint.com>
Add optional statistics around the channel publishing action. Store the
time a channel was last published to, and a total publish count.
This information can be used to determine how old a given channels data
is, and an average channel publishing frequency.
Signed-off-by: Jordan Yates <jordan@embeint.com>
ZBus currently does not have a `HEAP_MEM_POOL_ADD_SIZE_ZBUS` when using
message subscribers or runtime observers, forcing the developer to set that
manually. Adding the configuration option to zbus would improve its
usability and make zbus easier to use. With this feature, zbus aligns with
the other Zephyr subsystems' heap memory allocation approach.
Signed-off-by: Rodrigo Peixoto <rodrigopex@gmail.com>
Move the network buffer header file from zephyr/net/buf.h to
zephyr/net_buf.h as the implementation now lives outside of the networking
subsystem.
Add (deprecated) zephyr/net/buf.h header to maintain compatibility with old
file path.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
Remove `const` qualifiers on fields in structures that are only created
or instantiated as `const`.
This if primarily for consistency, in the same way that `struct device`
fields and `device->config` struct fields are not additionally marked as
`const`.
Signed-off-by: Jordan Yates <jordan@embeint.com>
Convert users of net_buf_put() and net_buf_get() functions to use
non-wrapped putters and getters k_fifo_put() and k_fifo_get().
Special handling of net_bufs in k_fifos is no longer needed after commit
3d306c181f, since these actions are now
atomic regardless of any net_buf fragments.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
Iterating the observations can be simplified to a struct iterator instead
of first getting the count and looping afterwards.
Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
Currently, zbus uses a single global `net_buf`pool to publish messages to
msg_subscribers. It would be good to have a way to separate the pools for
channels related to critical parts of the systems to avoid publication
failure on these particular channels. These channels will not use the
global pool. They can set an isolated pool by calling the
`zbus_chan_set_msg_sub_pool.`
Signed-off-by: Rodrigo Peixoto <rodrigopex@gmail.com>
The VDED was adding the channel information per clone. But it could be
done in the original buffer. This commit fixes that by adding the
channel information to the original buffer and not for each clone. As a
result, we have a more straightforward VDED execution with fewer copies.
Signed-off-by: Rodrigo Peixoto <rodrigopex@gmail.com>
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>
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>
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>
