Rockbox mail archiveSubject: Re: settings.c and testing config_block against 0xFF
Re: settings.c and testing config_block against 0xFF
From: Heikki Hannikainen <hessu_at_hes.iki.fi>
Date: Sun, 30 Mar 2003 16:27:37 +0300 (EEST)
On Sun, 30 Mar 2003, TP Diffenbach wrote:
> Is that the point of all the individual byte testing against 0xFF? To
> ensure that the current version's default (which may be different than a
> previous version's default, for some setting) is loaded if so indicated
> by 0xFF?
When I originally wrote the settings saving code, the idea was to not
increase the config block revision number when introducing new
configuration variables. To have the factory default applied in case the
config block doesn't contain a given variable (the byte is 0xff - this
happens when upgrading to a new version which has the same config block
version), and keep the config block backwards compatible with old RockBox
releases which use the same locations & formats for the settings that are
common between the versions (and thus have the same config block version).
I pretty much hate reconfiguring things when upgrading/downgrading/ROLOing
a new test build.
To rephrase that, the comment in settings.c says:
"Config memory is reset to 0xff and initialized with 'factory defaults'
if a valid header & checksum is not found. Config version number is only
increased when information is _relocated_ or space is _reused_ so that old
versions can read and modify configuration changed by new versions. New
versions should check for the value of '0xff' in each config memory
location used, and reset the setting in question with a factory default if
needed. Memory locations not used by a given version should not be
modified unless the header & checksum test fails."
Received on 2003-03-30