Hi Simon, > On Jun 9, 2016, at 4:59 PM, Simon Ratner <[email protected]> wrote: > ... > > At this point, only the new value is saved, and /cfg/run no longer contains > any of the previous values, even though config dump still has them all (ie. > the values in memory are correct, and export handler returns them). Of > course, after a power cycle, I lose my previously persistent settings. > > Worse, if at this point I try to manually re-set all settings to their > values, all except x/b are saved, so it seems the values are now in two > disjoint sets, and only one of the sets is saved on any particular call to > config_save. > > Any ideas on what is going, or pointers to what I am doing wrong? Is this a > side effect of the way flash blocks are written/erased?
The issue was that config save was blowing away all of the previous stuff. I.e. I imagined that all modules would every time ‘save’ gets called would store the configuration they want to keep around. But after using it like that for a bit decided that this is not a good model. And instead ‘save’ will keep appending to existing configuration. Or replace the previous value. I just pushed changes to develop which should make it behave like you expect. There’s still one wart that I’m aware of; during config load you’ll get called multiple times, if you’ve stored the config item with different value. The last call is the one that has the latest saved value. > PS. As a side note, I have observed some other general flakiness with > config + nffs. Sometimes the initial write partially fails and only some of > the data is saved, seems to be related to the file straddling the inode > boundary (only the data in the second inode can be read back). At other > times, nffs_detect fails after a previous write. Might all be related? That sounds like a bug in NFFS, probably worth pursuing. I don’t think that’s related to config behavior.
