Function now always rewrites old value under same key
regardless existing data type. Users requiring old API behaviour
can enable it by kconfig option CONFIG_NVS_LEGACY_DUP_KEYS_COMPATIBILITY
Users of the nvs API are likely to have `nvs_handle_t` in all cases, but
not all of them carry around the partition name and namespace name (as
they aren't needed after creating an `nvs_handle_t`).
Allow this common case to use nvs iteration without them tracking
additional data by using the `nvs_handle_t` to locate the namespace
index and the partition name by introducing an alterate to
`nvs_entry_find` called `nvs_entry_find_in_handle`, which operates
similarly except that it is given a `nvs_handle_t` instead of partition
and namespace strings.
This is somewhat more limited than the `nvs_entry_find` API as one
cannot examine all keys in a given partition.
- This features allows the NVS encryption keys to be derived and protected using
the HMAC peripheral. Since the encryption keys are derived at runtime, they
are not stored anywhere in the flash and hence this feature does not require
a separate `nvs_keys` partition.
With some libc impls (ie: Xcode 13.1), sprintf is marked as deprecated
and causes the build with `-Werror` to fail. Switch the `sprintf` usage
in test_nvs.cpp to use `snprintf` to allow builds to complete without
warning.
* nvs_page_test runs into timeout in CI. According to log,
test ran run around halfway, so increasing from 10 to 90 seconds.
* Also increased timeout of nvs_host_test, just to be sure
This fixes the issue that "idf.py partition-table" had to be run
manually in order for the partition table to be generated, when
building for linux target.
Host tests of nvs_flash eligible to run in Linux implementation of nvs flash were migrated. Remaining test cases
were left in original folder. Migrated test cases use CMake instead of make.
All the partition handling API functions and data-types were moved from the 'spi_flash' component to the new one named 'esp_partition'. See Storage 5.x migration guide for more details
Unlike COMPILE_OPTIONS, COMPILE_DEFINITIONS CMake property assumes
values without the -D prefix, such as NAME or NAME=VAL.
Previously, IDF build system was passing COMPILE_DEFINITIONS build
property to CMake COMPILE_OPTIONS property, so -D prefix was not
a problem.
Now that COMPILE_DEFINITIONS CMake property is used, -D prefix has
to be removed.
(Note that this doesn't affect 'target_compile_definitions' function,
which strips -D prefix before adding the definition to the property.)
