Rockbox mail archiveSubject: using config.cfg instead of config block
using config.cfg instead of config block
From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Wed, 15 Nov 2006 01:40:54 +1100
I have started up this patch again, and I'd like some feedback.
This patch completly replaces the config block by saving/loading
/.rockbox/config.cfg (and possibly system.cfg if it turns out its
Firstly, I just did a check and its currently 2200bytes bigger on the
h300, but this was expected, because the expected decrease comes from
simplifying the menu structure (which ill do once we are happy with
So, some points..
To save the settings to disk the ata_idle stuff is used, its callback
broadcasts a SYS_DUMPSETTINGS event, which if it is handled by
default_event_handler() will do a full save to disk of the settings.
I am doing this because if we try saving in the ata thread there is a
very good chance it will StkOv, so I figured it would be safer
(amiconn rekons default_event_handler() is only ever called from the
main thread which is why this should be safe). Is that OK?
Next thing, How should non-volatile settings be handled? the way it is
handled in the patch now is by using the non-volatile ram as an int
array, and just saving/loading the ints in order they appear in the
setting_list (they are saved if they have the F_SAVETORTC bit set),
Now, is there a better/more generic way to do this without adding much code?
There is alot of commented out code in the settings_save_config()
function, its purpose is to dump the valid values for each setting to
the disk when it saves... do we want this? (remebering it will slow
down saving a bit, and increase bin size)
Last thing, so you cant say I snuck a feature in, If a setting starts
with ~ before its name (like ~volume: ) then when saving the config
file its current setting will be ignored and the value that was loaded
will be saved instead.