On Sat, Jul 07, 2018 at 06:13:22PM +0200, Kevin Townsend wrote:
> In the sys/config package, there are two main flags to test against in
> code, depending on your implementation:
>
> * CONFIG_FCB (storage in FCB)
> * CONFIG_NFFS (storage in NFFS)
>
> https://github.com/apache/mynewt-core/blob/master/sys/config/syscfg.yml
>
> I'd like to add config key-pairs as an option to a sensor driver (the
> TSL2591 I submitted a PR for), to reload the integration time and other
> settings on startup, and persist changes when made, but am I correct
> that there isn't a single higher level 'CONFIG' flag and I'll need to
> test against both of the values above to determine if the config system
> is present or not? It seems not, but maybe I'm missing something.
>
> Would anyone else consider it 'cleaner' to add a single flag that is
> defined in either case (more if another persistance layer is added in
> the future), since the API itself makes FCB or NFFS (or ???) mostly
> transparent?
I think "package-present" settings are often not as useful as they might
seem. Most of the time, code doesn't care whether a package is present
in the build; it only cares whether it has access to the package. That
is, what matters is whether it has a dependency on the package, directly
or indirectly.
For example, the `sys/reboot` package depends on `sys/config`. Since
pretty much every build includes the `sys/reboot` package, `sys/config`
will be present, and all its settings will be defined and available to
the rest of the system. However, a driver package won't have access to
the `sys/config` header files unless it also depends on the package.
I think cases like the one you described are usually solved by adding a
new setting to the driver package (e.g., `TSL2591_CONFIG`). If that
setting is enabled, the driver package depends on `sys/config`, e.g.,
pkg.deps.TSL2591_CONFIG:
- '@apache-mynewt-core/sys/config'
> Kevin
>
> PS: As a side note, persisting the NFFS partition to an external file
> under ARCH_sim would make certain test cases easier., storing values
> across reets and builds. If this seems useful to anyone, I can raise it
> as a Github issue and look at putting a PR together?
I don't know if this helps in your particular case, but you can specify
"-f <path>" to use a local file for internal flash (assuming the app
calls `mcu_sim_parse_args()` in main). If you specify the name of an
existing file, the simulator will reuse its contents.
Chris
