FYI- I have submitted a PR for this feature here:
https://github.com/apache/mynewt-core/pull/1514
On Thu, Nov 08, 2018 at 10:29:19PM +0100, Kevin Townsend wrote:
[...]
> > 2. Remember which stats have changed since being persisted.
> >
> > Each stat needs a "dirty bit." There are two ways to do this:
> > a. Hijack the most-significant-bit of each stat.
> > b. Maintain dirty state in a separate bitmap in the stats module.
> >
> > Option a has some issues:
> > * We lose half the range of each stat.
> > * Looking at these stats in gdb will be quite confusing.
> >
>
>
> Yeah, this is less obvious or ideal. I agree that using the MSB is annoying
> for debugging, etc., and messy. But both options have issues. I'd say 'a',
> but neither is great. :( For the MSB approach, at least the values aren't
> signed which simplifies things and 2B is still a fairly large range.
As I mentioned in a follow up email, I decided to abandon the idea of
partial writes. Every write includes the entire stat group. The silver
lining is that the dirty bit issue disappears.
> Speaking of numeric limits ... another consideration persisting data is
> should we persist a rollover counter, and if so ... how and where?
That's a very good can of worms, er I mean point! The easy duck would
be to enforce saturation instead of wrapping in statistics. Then, stats
don't wrap, so there is no need for a rollover counter. If a stat is
likely to reach its maximum value, and the application needs to know
when it rolls over, then it can use an integer type with more range for
that stat.
If we did want to track rollover, then (totally off the top of my head)
perhaps a sys/config setting containing a sequence of the following
records:
<stat-group-name>:<stat-name>
Each time a stat rolls over, a new record would be appended. It would
then be up to the client (who is presumably interested in stats in the
first place), to erase this state after it has consumed it.
Chris
