|
Rockbox mail archiveSubject: using config.cfg instead of config blockusing config.cfg instead of config block
From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Wed, 15 Nov 2006 01:40:54 +1100 hey all, 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 needed). 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 this). 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. comments? Jonathan
Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |