From owner-freebsd-rc@FreeBSD.ORG Sat Dec 28 05:53:33 2013 Return-Path: Delivered-To: rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 342A4C3F for ; Sat, 28 Dec 2013 05:53:33 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EA9CF10BA for ; Sat, 28 Dec 2013 05:53:29 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id hk11so23460266igb.0 for ; Fri, 27 Dec 2013 21:53:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=SC/A030ObZuNv/cRYya0u9lIus+XkoKZCOcT6tOUvEk=; b=ceDGqgyM4bU8zJNRD99rmte/+fg9MQfbRjv9xhTiXy8YZzi2J/YwgaTFmY/b4CzBe/ Xd2dZA6OeNVVCw3vXvwvGiGhpkWIGLZY98awWOndiu0um690zHNyj740tVZ0UZY0m9v2 Pvdn2OPBHZebknrDkG6yKnXw94YGy2WRmVKtU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-type:content-disposition:user-agent; bh=SC/A030ObZuNv/cRYya0u9lIus+XkoKZCOcT6tOUvEk=; b=HUuAA/y63kIsQLBZ3Upq47aywjwx7RreOCf8mJWvKIyQaGwRW1R6pzVfuxChAfrkAN dwpdNhCMMdYtFzk031ASLk1CC6efAh24El1LnQdlbiiAtW/0ixorgu4GH62stYFAevCp cySpphy6MjVemfwbBlkuYFQuKTRLCfDaKXe4IGajBkJKiIQFeYk8rOYhrjJhIrusCr/z 49Cf0TOh1hEN5iLN0OHmOIehEt051CV1dbsvwR0E5nVBIQp94ZrUaHZMyZkA7DfFRRoA j6WPSM1uhu/FeekUKjKe9Tmai7qylObJtXh8Bsr5hTQ+TwejUW/iEzrIA/i+Q7xMknOc O+GQ== X-Gm-Message-State: ALoCoQntdEiwc+rNEoUYIqNoGgy2PTHVDxiGGfqeey/eZe7PaLkWTsFufY6p2UxcofZN7LjKJyH5 X-Received: by 10.50.120.71 with SMTP id la7mr138702igb.0.1388210009176; Fri, 27 Dec 2013 21:53:29 -0800 (PST) Received: from DataIX.local (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id w4sm48421123igb.5.2013.12.27.21.53.27 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 27 Dec 2013 21:53:28 -0800 (PST) Received: from DataIX.local (localhost [127.0.0.1]) by DataIX.local (8.14.7/8.14.7) with ESMTP id rBS5rO1v072792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Dec 2013 00:53:25 -0500 (EST) (envelope-from jh@DataIX.net) Received: (from jh@localhost) by DataIX.local (8.14.7/8.14.7/Submit) id rBS5rObN072791; Sat, 28 Dec 2013 00:53:24 -0500 (EST) (envelope-from jh) Date: Sat, 28 Dec 2013 00:53:24 -0500 From: jhellenthal@dataix.net To: net@freebsd.org, rc@freebsd.org Subject: network.subr _aliasN handling Message-ID: <20131228055324.GA72764@aim7400.DataIX.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2013 05:53:33 -0000 Curious what everyone's opinion would be on modifying the handling of _aliasN functions or providing a wrapper around it to handle non-sequential ordering. My goal on this is simple and based around groupings similiar to that of the way user id(1)'s in passwd and group are handled or denoted for use on modern systems. I.e.: I would like to achieve this... *_alias[1-99] = System type addresses "Importand addresses or internal" *_alias[100-199] = Aliases for interface 1 *_alias[200-299] = Aliases for interface 2 etc... NOt looking to achieve some sort of prefered naming convention for the interface aliases, but loosen them so they may be defined by the user in whatever means neccesary to their benefit. In a scheme similiar to above I attempted to set an address on every other 4th alias leaving 3 space rule room for insertion of further addresses but was surprised when the processing of the aliases ceased at the first non-sequential space. So why not just grab every _aliasN no matter of what it is for the interface and shove them into an arrary to be processed by a "for" statement ? the order would still be kept without having to inspect every defintion of alias and incrementing prehistorically. As well this could provide early loading of the addresses into their respective arrays so they may be processed and provided to any other functions that may need to access them earlier on in script fallthrough. Looking at _alias'N' sequentialy feels like a neucense.