Date: Thu, 02 Oct 1997 00:41:48 +0930 From: Mike Smith <mike@smith.net.au> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG Subject: Re: Interface configuration : call for ideas. Message-ID: <199710011511.AAA00666@word.smith.net.au> In-Reply-To: Your message of "Wed, 01 Oct 1997 04:09:22 MST." <11625.875704162@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ah, some input! I thought you were busy? If this is the quality of
feedback I get from busy people, we must be alone here... 8(
> > 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.
Fair enough. The ultimate goal was actually to have the majority of
systems with a single 'ifconfig_lan' directive and nothing anywhere
naming a specific driver. The only ones that would require this would
be those with more than one interface, a relatively rare thing.
> 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.
This isn't actually very helpful; it just means @ = "lan", and that's
only going to confuse people. I was originally going to say "ether"
rather than "lan", but decided that there were "lan" interfaces that
weren't "ether". Still, it's a hack rather than a good solution, I
agree.
> 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?
Because the actual set of event-response sequences are very small, with
just a few opt-in/opt out items?
> 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.
It's certainly an insult to generality, agreed.
> 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.
Not unreasonable.
> 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"
Fair enough. This sort of shell syntax would get pretty cramped pretty
fast unfortunately, but the idea works.
> 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? :-)
OK here. I'm not sure how others will buy it. Perhaps a POC
implementation is called for? How do people feel about a potentially
new directory in /etc for files associated with this sort of thing?
Is there any way in sh of determining the existence of a function?
mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710011511.AAA00666>