On Wed, 2009-01-21 at 15:41 +0100, Bastian Bittorf wrote: > > KISS! Heh. KISS would have been leaving the config in the NVRAM as it was intended. :-)
> Just write an script which tar->gzip->uuencode's your prefered config-files So now I need to know what all configuration files are behind whatever web gui I'm using to ease configuration of my router? I am sure to forget one. If this became an official feature, it would continually need updating to know about all of the configuration files every package has. Maybe the list of configuration files can be queried from the package inventory database. That would depend on developers correctly flagging configuration files. What happens when the format of a configuration file changes from one release to another? You can't just roll a tarball down and overwrite newer formatted files with older formatted ones. This just feels like a fragile solution. But I don't think you are getting my point. Why should *I* have to have knowledge of all of the config files that might be getting used and (write a hack to) back them up and have to restore them? > into nvram-partition (if your hardware has one), I really have little knowledge of how the NVRAM partition works so would be handicapped to use it as you describe. I really don't want to have to understand these routers to this level just to make my upgrading process more sane, but I will take this opportunity to learn a bit more. Are there any docs out there on how one can use the NVRAM partition for this sort of task? Is it just a block device I can read/write to or is it more complicated than that? > which is (if existent) restored > at firstboot (just mark with e.g. "touch /www/firstboot_was_done") from > nvram. Seems reasonable. But is it foolproof? > Where is the problem? Just in that this is something I have to do on my own. This is something that should have been done when the decision was made to not use NVRAM as it was supposed to be used. The whole thing was done as a half-solutions. > If you wait some weeks I will deliver a patch > because we need exactly this functionality in our firmware Excellent! Be sure to post it here for consideration of merging into the official tree. > - we plan > to upgrade from whiterussian/freifunk to kamikaze trunk/b43wifi b43 wifi as an AP? My experience is that AP mode is not ready. When you push lots of data through it, tt chews up all of the CPU with softirqs to the point that the CPU becomes a bandwidth bottleneck. See my previous posts here about it. My testing was on a Linksys WRT54GS, v1.0. Maybe your experience is different. b.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ openwrt-devel mailing list [email protected] http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
