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>
Multiple components may use the settings subsystem, so ensure
settings_subsys_init() is thread safe.
Signed-off-by: Stig Bjørlykke <stig.bjorlykke@nordicsemi.no>
Devices with write block size greater than 16 could not use settings_fcb
due to small buffer size.
Update value in test as well.
Signed-off-by: Nicolas VINCENT <nicolas.vincent@vossloh.com>
Prototypes of those functions are already in header files in
subsys/settings/include/settings/ directory, so no reason to have
duplicates in C files.
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
There is already CONFIG_SETTINGS_FILE_PATH, which is set to full file path,
while CONFIG_SETTINGS_FILE_DIR is required to be set to its parent
directory. This is redundant, as parent directory path can be easily found
out either during runtime or optionally during buildtime by CMake.
CONFIG_SETTINGS_FILE_DIR was actually introduced recently after Zephyr 3.2
release as a replacement of deprecated CONFIG_SETTINGS_FS_DIR. This means,
that there is no need to deprecate it for 3.3 release and dropping it
should be fine. Adjust 3.3 release notes accordingly, so that
CONFIG_SETTINGS_FILE_PATH will be used directly.
This patch stops using deprecated CONFIG_SETTINGS_FS_DIR. There is actually
no value in respecting it, as setting anything other than parent directory
of CONFIG_SETTINGS_FS_FILE makes no sense.
There is actually one use of CONFIG_SETTINGS_FILE_DIR in file backend
tests, to derive directory for files containing tested settings.
CONFIG_SETTINGS_FILE_PATH is not used there, so it makes little sense to
derive directory name from it. Instead, just use hardcoded "/settings"
subdirectory, as this was the default value of CONFIG_SETTINGS_FILE_DIR.
Deriving parent directory can be done either in runtime or in
buildtime (e.g. using some helper CMake function). Doing it in runtime
however allows to create directory recursively (which this patch actually
implements), e.g. for some more nested FS tree structure. Additionally it
will simplify migration of settings configuration from Kconfig to
device-tree (yet to be developed feature).
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
There is little reason to panic on settings backend initialization error.
Such behavior was introduced with initial settings subsystem support, which
was adapted from MyNewt. This is not the usual way how Zephyr handles
errors, so it is time to change that.
There is already handling of some errors by simply returning / propagating
them to caller. Rework all the paths that resulted in k_panic() to also
return error codes.
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
File backend can be read-only with the use of `settings_file_src()` API. It
makes no sense to create file when `settings_load()` is called and
registered file backend won't be used for saving files (because
`settings_file_dst()` was not used).
Do not create file during `settings_load()` if it does not exist yet. This
just requires to remove FS_O_CREATE flag in `fs_open()` invocation.
Open file with read-only access, which is now possible after removal of
`FS_O_CREATE` flag.
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
`settings_fcb_save_priv()` already takes `const char *value`, so there is
no reason to cast to `char *` before passing.
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
`settings_file_save_priv()` already takes `const char *value`, so there is
no reason to cast to `char *` before passing.
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
This function was refactored several times due to many features (like
base64 encoding), which got deprecated over time. Simplify it a bit now.
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
This macro is not used anymore and is strictly a leftover, which should be
removed as part of commit 55be783c85 ("settings: Remove deprecated
SETTINGS_USE_BASE64 support").
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
Put all options under one `if SETTINGS` block, so that `depends on
SETTINGS` does not need to be repeated every time.
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
Use CONTAINER_OF() macro to access outer backend-specific structure. This
removes the requirement to keep `struct settings_store` as the first item
in outer structure.
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
Currently there is inconsistency in repository file names, APIs, Kconfig
options and documentation around file / file-system backend for settings
storage, as both "file" and "FS (file system)" are used. As an example,
there is `CONFIG_SETTINGS_FS` Kconfig option, but the file that implements
this settings backend is called `settings_file.c`. Another example are
names of static functions that implement settings storage API:
`settings_file_load()`, `settings_file_save()` and
`settings_fs_storage_get()`.
This backend is actually storing all settings in a single file, so it makes
sense to use "File" as the name of backend, instead of a more general
"FS" (which would make sense if several files would be used to store
settings).
Fix inconsistency in used wording in the tree and unify it to "settings
file backend". This naming is more precise to how the implementation looks.
It will also make it easier to grep through the codebase and analyze
existing code.
Deprecate settings_mount_fs_backend() function and all Kconfig options
starting with `CONFIG_SETTINGS_FS`.
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
The commit switches flash area access from FLASH_AREA_ macros
to FIXED_PARTITION_ macros and to usage of DTS node labels,
to identify partitions, instead of label property.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
On MCU with bank swap capabilities, the offset of the storage area is
not the same before and after a bank swap. This commit introduce a weak
function which returns the default flash area of the storage partition.
On MCU with the bank swap capability the user can define its own
function to get the proper flash area depending on which bank the fw is
run from.
This commit is a workaround for #47732
Signed-off-by: Nicolas VINCENT <nicolas.vincent@vossloh.com>
Added API function +int settings_storage_get(void **storage)
which allows to get storage instance used by the
settings backed to store its records.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Logging v1 has been removed and log_strdup wrapper function is no
longer needed. Removing the function and its use in the tree.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
