On Nov 26, 2012, at 9:44 PM, Christian Weisgerber <na...@mips.inka.de> wrote:
> Todd T. Fries <t...@fries.net> wrote:
>
>> If there are desires to improve this (I hear Naddy grumbling!) then the
>> stomach to break backwards compat must be present, or suggestions on how
>> to do it without breaking backwards compat must be suggested.
>
> My suggestion is two-fold:
>
> * Introduce a new format. This new format will ignore # comments,
> call ! commands, but otherwise pass on everything unchanged to
> ifconfig. I'm neutral on the matter of retaining "dhcp" and
> "rtsol" as shortcuts for "!dhclient \$if" and "!rtsol \$if".
>
> * To maintain backward compatibility, retain the old parsing for
> hostname.* files. Interface configuration files in the new format
> will have a different name; if.* or whatever.
>
> Does that sound workable?
I like new format, but I'm not sure the road to go should be the
hostname.if type of format. Ordering could be imposed on such a
format in the likes of whatnot.if.priority - and you'll end up
with a mess of configuration files.
So how about a single new config file (implemented in the style of
Christian's suggestions, which also provides the following things:
(1) new syntax is invoked like this:
if {
up
down
}
(It would also be possible to provide inline backwards compatibility
with the old syntax, but I don't think this file is the right place
to put it, see below)
(2) the old style hostname.if files are invoked using solely this:
if
(3) allow wildcards to be used, so that the default and fully
compatible file is:
*
If you don't like the hostname.if stuff, you simple delete the config
file or remove/comment out that wildcard line. You can also impose
ordering this way, but you're on your own then:
re0
re1
# invoking * would be stupid now...
Next issue would probably be running external scripts in the new
format from this file. Maybe like so:
if /path/to/settings
The syntax is debatable, and there are probably a few consistency
considerations: what is executed in the old format and what is
not? But then this format would be something to migrate to if it's
feasible, so maybe the only backwards compatible way should be
for (2).
Franco
