I apologize if I'm jumping in and missing something, or repeating what's already been stated.
As mentioned, I think that creating a common abstract configuration interface that uses a device-dependent backing store (exposed through another abstract interface) is the way to go here. For instance (high level view, of course can be implemented entirely by free functions): Package X -> IConfiguration -> IDeviceDependentStore All packages an other system components would invoke the common IConfiguration interface, which would, amongst other things, determine the platform currently running and use the appropriate IDeviceDependentStore to actually store and retrieve configuration items. ........................... Now, for backing storage on the Boradcom routers specifically: Although the CFE (amongst other things) does use NVRAM variables, preventing a complete overhaul of the NVRAM to a proprietary storage, it should be possible to do something like leave the first 8kb for standard NVRAM variables and use the remianing 24kb for proprietary storage. The nvram storage format, iirc, is simply an array of null-terminated strings, with the terminating string having a length of 0 (two NULLs terminate array). In example: NVRAM (in kb) [0-7]: Standard format [8-31]: Proprietary format One could compress the data stored in the last 24kb and fit quite a lot of configuration data there -- I think probably as much as anybody needs. There'd need to be certain checks to make sure somehow the standard NVRAM data never exceeds 8kb, but this shouldn't be a big deal, and should be plenty of storage. One could even grow the proprietary storage backwards from the end, always leaving the maximum amount of room for standard NVRAM storage. There are advantages and disadvantages to using the NVRAM though. One obvious advantage is that this area will be preserved in a firmware upgrade. The beauty of abstracting things as shown above is that even for the same platform, multiple types of stores can be developed and the user (or developer) can pick the one that works the best in their particular circumstances. -- db90h _______________________________________________ freewrt-developers mailing list [email protected] https://www.freewrt.org/lists/listinfo/freewrt-developers
