Documentation Request for NVS and SETTINGS_NVS

[kiafaldorius]

Is your enhancement proposal related to a problem? Please describe.

It's my understanding of the settings_nvs.c and its usage of NVS_NAMECNT_ID and NVS_NAME_ID_OFFSET that the settings will only use NVS key indexes from NVS_NAMECNT_ID up to NVS_NAMECNT_ID + (NVS_NAME_ID_OFFSET * 2).

This means key indexes below NVS_NAMECNT_ID and above NVS_NAMECNT_ID + (NVS_NAME_ID_OFFSET * 2) (as long as it's not maxed out) are available for userspace application usage.

Describe the solution you'd like

If my assessment above is correct, can we add some documentation to:

• The NVS page https://docs.zephyrproject.org/latest/services/storage/nvs/nvs.html to mention this
• Additional help text to the SETTINGS_NVS KConfig https://docs.zephyrproject.org/latest/kconfig.html#CONFIG_SETTINGS_NVS

Being able to reuse the default board storage dts entry for both userspace and settings is very useful. This lets developers avoid having to split flash space into an NVS partition for application data and another for settings data. Having this larger single partition could help with wear-leveling also.

A few lines of documentation can save quite a bit of developer headache and time trying to figure this out themselves.

This is especially important since I believe Zephyr is shifting to NVS as the default storage backend.

Describe alternatives you've considered

I have not considered any alternatives to not documenting this. I don't see the harm in adding a few lines of documentation, unless of course, my initial assessment is wrong. We obviously should not add incorrect implementation details to the documentation.

[Laczen]

@kiafaldorius, yes it has been foreseen from the addition of a nvs backend to settings that the nvs backend could be used by both settings and userspace. However because of how settings initializes it was very difficult to use it this way, so it was never documented. A recent addition (#48420) has made it possible to get the nvs backend and now this feature can be used more easily. The documentation has not yet been improved. There still are some quirks to use it as the settings subsystem needs to be up and running before accessing the nvs backend.

You are welcome to provide a PR that documents this feature.

As the main author of nvs I consider nvs to be EOL, and would no longer advise this for new devices. The main reasons for this are: limitation to only use flash as a backend, not really fit for larger write-block-sizes (more and more devices appear with this property), no (simple) possibility to add encrypted storage, ...

[kiafaldorius]

@Laczen Thank you for the confirmation! What's your recommendation for a storage backend? I'm on NRF52832, an older chip, but starting a new project. NVS is still the default for Zephyr, so I assume it's good enough.

I'll look into updating the documentation, but I'm running 3.1 so settings_fs_storage_get doesn't look available to me yet. In the meantime, I've been able to manually initialize the nvs_fs with (what should be) the same options used to initialize the settings fs. It does feel dangerous, but appears to work.

[Laczen]

I'll look into updating the documentation, but I'm running 3.1 so settings_fs_storage_get doesn't look available to me yet. In the meantime, I've been able to manually initialize the nvs_fs with (what should be) the same options used to initialize the settings fs. It does feel dangerous, but appears to work.

Don't do this, when there are two threads writing the userdata and the settings at the same time the lock mechanism does not work and the nvs_fs might get corrupted.

[kiafaldorius]

the nvs_fs might get corrupted.

And that's why it feels dangerous... I'll heed the warning and use the settings subsystem for my userdata until I get around to updating my libraries. Thanks again.