> > thats why UCI was invented > > I would have suggested some kind of "on disk" nvram emulation for such > non-nvram capable systems so that the nvram paradigm remains the same > for nvram capable systems and is emulated for others that have, say, > persistent disk. 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?
In this one dimension you cannot clearly create relationships between configuration options, you technically only have 1 datatype and you mess configurations together. I've heard that some other firmware projects use nvram-emulation but this is definitely very ugly. You will end up having lots and lots of abandoned configuration strings in your nvram if you use it overtime, install and uninstall packages etc. Clearly nvram has only disadvantages compared to UCI. > > But given the advances made with sysupgrade, this might be getting moot. > I guess only time will tell if my fears of synchro problems between > config files and sysupgrade manifest themselves. That is a problem that OpenWrt will face in the future when it comes to changes in some package/subsystem UCI format but you would and already had faced similar problems with nvram. > > That said, I wonder if sysupgrade has a "user driven" inventory list -- > that is, a list of files to be included in the sysupgrade save set that > the user can define. It has. > > > It think this is a clean way > > Agreed, with the above idea. > I disagree because that would create an unwanted relationship between ipkg and sysupgrade and also will result in having old configuration files if new versions of packages also have updated configuration files. > > anyway - if a config file changes you have always some fiddling by > > manual configuration. The most important thing is IMHO, that all > > network related stuff starts as usual. Probably networking stuff just just be kept backwards-compatible and/or include a conversion mechanism if a change is needed. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
