Closed eHammarstrom closed 2 years ago
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).
How about a zephyr,settings,nvs
property in /chosen
?
@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?
@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.
@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)
zephyr,settings
is fine if it's not possible to have multiple settings providers simultaneously. The fallback is also a good idea.
Adding myself and @nvlsianpu to the thread.
@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
. IfDT_CHOSEN_zephyr_settings
is undefined it could fallback toFLASH_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 ?
@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
. IfDT_CHOSEN_zephyr_settings
is undefined it could fallback toFLASH_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.
@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 , 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.
@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.
@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 , 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.
Enabling
CONFIG_SETTINGS_NVS
will result insettings_nvs.c
initializing and using the flash area labeledstorage
, 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 sosettings_subsys_init(struct flash_area *fap)
. This would entail an API update and updating the backends accordingly.