|
Rockbox mail archiveSubject: Re: settings.c and testing config_block against 0xFFRe: 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." - Hessu Received on 2003-03-30 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |