From owner-freebsd-hackers Wed Oct 1 08:14:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA18925 for hackers-outgoing; Wed, 1 Oct 1997 08:14:43 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA18916 for ; Wed, 1 Oct 1997 08:14:36 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id AAA00666; Thu, 2 Oct 1997 00:41:51 +0930 (CST) Message-Id: <199710011511.AAA00666@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Jordan K. Hubbard" cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: Interface configuration : call for ideas. In-reply-to: Your message of "Wed, 01 Oct 1997 04:09:22 MST." <11625.875704162@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Oct 1997 00:41:48 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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