Nvram_get

[Fidelia Boldul]

Firstthank you for answering my question on nvram policy. I have thought about a configuration scheme along the same lines that tries to be more flexible to configure than nvrams notion of wan/lan interfaces and more straight forward to understand and customize than currently.

I'd suggest to first look into the "interfaces" file then domains and firewall. They are supposed to be sourced from a init.d or helper scripts similar to functions.sh. Instead of invoking nvram_get directly with a logic that tends to be specific to only a subset of possible setups, the logic could iterate over whatever interfaces are defined.

The NVRAM area is already allocated, with access methods already defined. We don't save any space by deleting NVRAM variables, nor do we gain anything by ignoring existing variables and duplicating them in a config file. Unfortunately the existing NVRAM variables don't lend themselves well towards multiple vlan groupings, pushing us towards a separte means of configuration.

While a nice easy to read config file would fit in with openwrt's current commandline interface and may be trivial to maintain by hand, creating a web interface that's able to display the current configuration and selectively change values becomes much more difficult. One variation I'd suggest is splitting the configuration up into smaller groups; instead of parsing one massive file you'd break it up by work loads, simplifying the parse. Example:

By creating a separate file per interface, our parser nolonger has to keep track of which interface the config line refers to and each interface file can reuse the same set of variables making it simpler for a script to modify settings.

Hmm, not sure if it is really that much harder to "parse" a single file than several tiny ones. For hand editing I'd prefer one file for interfaces for example. The files arent't actually that massive as it may have looked like copied into a single post ;-) Most of the config file lines were comments anyway.

For the subset of configurations that can be represented by nvram setting the webinterface just needs to do nvram sets, as always. But if desired an expert mode could easily represent and modify the config files to I think. Depending on the webfrontend implementation the script could source the variables set in the config files directly or query a tiny bash helper script to get settings. And changing values could be as easy as

s/vlan3_address=/vlan3_address=

(plus a interface stanza create (cat some-lines >>) and delete (sed delete-some lines) function)

To configure the router I had to go through all the startup scripts first and had to at least partly understand how they worked before I could figure out which nvram varables where used for what and how, and be able to start changing the configuration without just guessing.

What I am trying to achieve with the config files is that new users can get an idea and overview of how to configure their router up front. Most of the variable definitions are just gathered from the existing initscripts anyway, so it shouldn't be much duplication, rather a consolidation maybe.

Another benefit I see is when OpenWRT is more generically configurable in configfiles without changing things in the initscripts themselves it can be consistent across more different hardware. (just provide different default config file)

- make the boot/configure scripts more universal

(clean up parts that currently hardcode specific configs, especially functions.sh, probably create a ifup/ifdown scripts from it that sets up the interfaces as defined in /etc/network/interfaces)

Hi,

cool, noticed function.sh has been split up into ifup/down. I too, sat down some more and worked on this. I'd need someone who could proofread what I did though. mbm could I send the modified files to you? I've made a little tarball.

I agree with mbm. Anything that makes it easier to make a web interface gets my vote. I would prefer a file for each interface. I don't think that NVRAM variables are going to work for a web interface - at the moment we are currently hamstrung by original interface configuration that the NVRAM variables are built around. So how do we proceed? How should NVRAM variables interact with config files? Why should we continue to use them? What method gives us the most amount of flexibility without creating piles of files that eat up valuable flash memory?

3a8082e126