On Thu, Jan 22, 2009 at 06:46:10PM +0100, Steven Barth wrote: > Why emulate a 1 dimensional limited configuration system for all platforms, > with a maximum capacity of 32kiB just because ONLY some old broadcom based > routers use it?
Right. NVRAM was usually a 32k block of consecutive name=value string pairs. - limitations on the size and character set of 'name' and 'value' - no ability to add comment or make the configuration user friendly and no ability to temporarily comment out an item - naming scheme for variables was nonstandard with each vendor using slight variations - certain variables were required at bootup before the firmware loaded, erasure of those variables or the inability of the loader to parse them rendered the device unbootable until nvram could be reprogrammed externally with a JTAG After running a few different firmwares you often had a multiple sets of variables, each conforming to whatever oem naming scheme that firmware used, making it difficult to tell which set of variables controlled the current configuration. The "reset to defaults" button found in many firmwares didn't attempt to clear out old variables, it simply reset the variables used by that firmware to default values. It was nearly impossible to clean out the unused variables for fear that the variable might be required by the boot loader of that particular device, rendering the device unbootable if that variable was removed or changed. Some devices included boot loaders that would repopulate NVRAM with a default set of variables if none were found, other devices had boot loaders which would attempt to repopulate NVRAM but would do so using variables/values that were incorrect for that type of device -- the result of the same boot loader code being used on multiple devices. We wanted to keep the unix style of human readable configuration files stored in /etc, but it was impractical to write a web interface when each utility used a slightly different config format -- you needed to be able to read in the entire configuration file, understand it, make one small change to the appropriate line in the file and then write out the new configuration file. UCI was created as a very user friendly confile file which could be easily parsed with a few lines of shell script. Of course, now that we'd chosen to remove NVRAM, and put the configuration data in the filesystem, how do you keep the filesystem across a firmware upgrade? Or, rephrased, why does the filesystem get nuked durring an upgrade? The problem really comes down to space -- 4M of flash isn't much space when you have to share it with bootloader, kernel, filesystem, nvram .. etc. The bootloader and NVRAM are pretty much fixed, but the firmware is allowed to do whatever it wants with the remaining space, so pack a kernel into the smallest possible size and then immediately after it, create a filesystem. Great. Now what happens if the next version of the kernel is a different size? Now you need to move that filesystem. Why can't we put the kernel in the filesystem so we'd never need to move the filesystem? Good idea, except how do you boot it? There needs to be some code at bootup that understands the filesystem and is able to extract the kernel, between the new bootup code and the overhead of the filesystem you've now used more space than just putting the kernel directly on flash where it could be booted by the exisitng bootloader. Similarly, we don't want to have free space between the kernel and filesystem to allow future kernel growth -- we don't exactly have a luxury of space on most devices. We came up with the idea of switching to a ramdisk and reflashing fairly early in the kamikaze development. The concept is pretty straight forward -- stop whatever you're doing that uses flash, copy the running system to a ramdisk, reflash, copy back -- the actual implementation isn't as simple, you can't just tell an application "stop using flash", it's often impossible to get it to free file descriptors without killing it, so it's only with in the last few release canidates that we've had sysupgrade functionality working. I could probably go on for several more chapters, but that's enough of an explaination for now. - Mike. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
