Settings nvs subsystem uses a hardcoded flash area label

[eHammarstrom]

Enabling CONFIG_SETTINGS_NVS will result in settings_nvs.c initializing and using the flash area labeled storage, which is hardcoded in the subsys init function.

I would prefer if this partition label was configurable, so I could choose where the Settings subsys stored NV params.

Considered using Kconfig for this label, but Kconfig does not supported unquoted strings to produce a label. The flash area partition id could also be passed when calling the settings_subsys_init(void) function, like so settings_subsys_init(struct flash_area *fap). This would entail an API update and updating the backends accordingly.

[Laczen]

Another option could be to introduce a Kconfig variable: SETTINGS_NODEFAULT, enabling this variable could remove the settings_backend_init() so that you could write your own settings_backend_init() function and give full control over the backend(s).

[pabigot]

How about a zephyr,settings,nvs property in /chosen?

[eHammarstrom]

@pabigot I am not familiar with the chosen node, but by the looks of it you would reference the partition by alias zepyhr,settings,nvs = &my_settings_partition;, and thereafter use DT_FLASH_AREA_ID(DT_LABEL(DT_CHOSEN_zephyr_settings_nvs))) in settings_nvs.c. Is this assumption correct?

[pabigot]

@eHammarstrom Yes. Using a chosen devicetree property is how we're generally addressing the question of selecting which resource is to be used to support a standard feature, like a console. There's a list around here.

[Laczen]

@pabigot, yes this is a good idea. It wouldn't enable the more advanced features of settings (using multiple backends) but at least it would allow easy selection of a partition to use/override. As at the moment it is not possible to select multiple backends a zephyr,settings poperty in /chosen might be a better name, this could then also be used for e.g. fcb. If DT_CHOSEN_zephyr_settings is undefined it could fallback to FLASH_AREA_ID(STORAGE)

[pabigot]

zephyr,settings is fine if it's not possible to have multiple settings providers simultaneously. The fallback is also a good idea.

[de-nordic]

Adding myself and @nvlsianpu to the thread.

[MathieuGeorges]

@pabigot, yes this is a good idea. It wouldn't enable the more advanced features of settings (using multiple backends) but at least it would allow easy selection of a partition to use/override. As at the moment it is not possible to select multiple backends a zephyr,settings poperty in /chosen might be a better name, this could then also be used for e.g. fcb. If DT_CHOSEN_zephyr_settings is undefined it could fallback to FLASH_AREA_ID(STORAGE)

@Laczen , I'm looking to use settings subsys with multiple backends (nvs + fcb + custom backend). Is this feature already available or is it in the roadmap ?

[Laczen]

@pabigot, yes this is a good idea. It wouldn't enable the more advanced features of settings (using multiple backends) but at least it would allow easy selection of a partition to use/override. As at the moment it is not possible to select multiple backends a zephyr,settings poperty in /chosen might be a better name, this could then also be used for e.g. fcb. If DT_CHOSEN_zephyr_settings is undefined it could fallback to FLASH_AREA_ID(STORAGE)

@Laczen , I'm looking to use settings subsys with multiple backends (nvs + fcb + custom backend). Is this feature already available or is it in the roadmap ?

@MathieuGeorges, no I don't think this is possible at the moment. It should be possible to use settings with multiple custom backends, but not with the builtin nvs and fcb. I have no plans to work on this.

[MathieuGeorges]

@Laczen , thanks for your answer, so I only see one solution at this time : Implement a custom backend as an abstraction layer which will implement nvs + fcb + custom backend.

[Laczen]

@Laczen , thanks for your answer, so I only see one solution at this time : Implement a custom backend as an abstraction layer which will implement nvs + fcb + custom backend.

I don't think this will work, the problem is that the routine settings_backend_init() is defined in both the nvs and the fcb backend, so you can't select support for settings on nvs and fcb. This would first need to be removed.

[Laczen]

@MathieuGeorges, you can find my original comment about this in the PR that introduces the settings_backend_init() at the time (#20975). I propose you take this up with the original approvers of the PR.

[MathieuGeorges]

@Laczen , I found this comment (19798) in a proposal you've made. This "backend splitter" would be a good workaround since I only need 2 backends : NVS and a custom backend. Do you know if there are implementations of this kind ?

[Laczen]

@Laczen , I found this comment (19798) in a proposal you've made. This "backend splitter" would be a good workaround since I only need 2 backends : NVS and a custom backend. Do you know if there are implementations of this kind ?

No, I don't know about any implementation that uses this method, sorry.