Hi, On Fri, 30 Jun 2006 at 13:25 -0400, Bitsum Technologies Support wrote: > 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.
Thanks for the input. I think the abstraction layer could be done
via a special fuse filesystem, which emulates a normal /etc in one
or two special flash blocks. On nvram based system we can share data
in the nvram partition.
A separate /etc partition with jffs2 would be bad, because jffs2
needs 5 free blocks to even work. So a proprietary backend, which
uses compression would be the best thing.
May be Joerg has some time to get his idea written in C ;)
bye
Waldemar
--
don't open your wrt, free it
http://www.freewrt.org
pgp9B69bwcgnZ.pgp
Description: PGP signature
_______________________________________________ freewrt-developers mailing list [email protected] https://www.freewrt.org/lists/listinfo/freewrt-developers
