Date: Wed, 01 Oct 1997 04:09:22 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Mike Smith <mike@smith.net.au> Cc: hackers@FreeBSD.ORG Subject: Re: Interface configuration : call for ideas. Message-ID: <11625.875704162@time.cdrom.com> In-Reply-To: Your message of "Wed, 01 Oct 1997 00:18:58 %2B0930." <199709301449.AAA00810@word.smith.net.au>
index | next in thread | previous in thread | raw e-mail
> ifconfig_ed0="inet 10.2.3.4"
> ifconfig_lan="inet 10.5.6.7"
1. I think that having to know the name and class of any given ethernet
driver so that one can properly understand the "fall through" behavior
is probably asking a bit much of the administrator. Right now it's
not *totally* obvious when the value of, say, "ifconfig_ed0" is going
to be used, but at least there's a one-to-one correspondence.
If you're going to try and implement your behavior along these lines,
I might suggest that something closer in ideology to "wildcarding"
be adopted, e.g. "ifconfig_@" would be equivalent to "ifconfig_lan"
in your example (I'd like to use * instead of @ there but that'd
probably lead to globbing problems :). I think that'd be easier
to understand as a general rule than having to know more about the
attributes of an interface.
2. If you're going to go the full route of having "arrival events"
being paired up with associated actions, why go with the kludge
above at all? It seems to me that creating lots of ifconfig_foo
and route_static_bar variables which essentially do no more
than add conditionals to a fixed scripting sequence
(e.g. rc.network) is counterproductive in what you're trying to do
here. Why not something closer to a variable naming syntax like:
${eventClass}_${eventName}[_${objName}]
Meaning that for arrival event foo of class bar for object fnord, you
execute the contents of ${bar_foo_fnord} if found, falling back
to ${bar_foo} if that doesn't exist and, finally, doing no action if
the 2nd lookup fails.
Some practical (though highly contrived) examples:
Events "up" and "down" are in class ethercard, these being your
new variable entries:
ethercard_up="ifconfig \${objName} inet 10.5.6.7"
ethercard_up_ed0="ifconfig ed0 inet 10.2.3.4"
ethercard_down="ifconfig \${objName} down"
Note that you also get to use the implicit wildcarding feature
for ethercard_down since you don't need an interface specific
line for it. Needless to say, certain variables like ${objName},
${eventName}, etc would also be set before doing a final
expansion of the variable and passing it off to execution,
allowing you reasonable access to important parameters.
Optional scripts could be looked for and executed using
similar logic.
Or is that too radical? :-)
Jordan
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11625.875704162>