From owner-freebsd-hackers  Wed Oct  1 04:09:47 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA06418
          for hackers-outgoing; Wed, 1 Oct 1997 04:09:47 -0700 (PDT)
Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA06412
          for <hackers@FreeBSD.ORG>; Wed, 1 Oct 1997 04:09:40 -0700 (PDT)
Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id EAA11661; Wed, 1 Oct 1997 04:09:23 -0700 (PDT)
To: Mike Smith <mike@smith.net.au>
cc: hackers@FreeBSD.ORG
Subject: Re: Interface configuration : call for ideas. 
In-reply-to: Your message of "Wed, 01 Oct 1997 00:18:58 +0930."
             <199709301449.AAA00810@word.smith.net.au> 
Date: Wed, 01 Oct 1997 04:09:22 -0700
Message-ID: <11625.875704162@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>    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