From owner-freebsd-rc@FreeBSD.ORG Fri Feb 21 17:05:41 2014 Return-Path: Delivered-To: rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91882CA5; Fri, 21 Feb 2014 17:05:41 +0000 (UTC) Received: from secure.freebsdsolutions.net (secure.freebsdsolutions.net [69.55.234.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C6B8156D; Fri, 21 Feb 2014 17:05:38 +0000 (UTC) Received: from [10.10.1.198] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by secure.freebsdsolutions.net (8.14.4/8.14.4) with ESMTP id s1LH5MB7069039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Feb 2014 12:05:22 -0500 (EST) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: network.subr _aliasN handling From: John Nielsen In-Reply-To: Date: Fri, 21 Feb 2014 10:05:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7EAEF3AC-DB1B-4D3E-A156-E1E76B765990@jnielsen.net> References: <20131228055324.GA72764@aim7400.DataIX.local> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com> To: Devin Teske X-Mailer: Apple Mail (2.1827) X-DCC-x.dcc-servers-Metrics: ns1.jnielsen.net 104; Body=4 Fuz1=4 Fuz2=4 X-Virus-Scanned: clamav-milter 0.97.8 at ns1.jnielsen.net X-Virus-Status: Clean Cc: Jason Hellenthal , "rc@freebsd.org" , "net@freebsd.org" 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: Fri, 21 Feb 2014 17:05:41 -0000 On Jan 4, 2014, at 4:25 AM, Teske, Devin = wrote: > On Jan 4, 2014, at 2:59 AM, Jason Hellenthal wrote: >=20 >> I believe I know what you mean by that but in a way scares me when = you say sort as in mixing up the original order they appear in which I = would find to be really unattractive to most. >=20 > It's not as scary as it sounds. >=20 > The issue is that the variables are sorted alphabetically, instead > of numerically. >=20 > Let's take four words: foo1, foo2, foo10, and foo20. > If you sort them alphabetically, you get: >=20 > foo1 > foo10 > foo2 > foo20 >=20 > You'll notice this when doing a directory listing, as that too is = sorted > alphabetically. >=20 > This is why "alias14" is run before "alias8" and "alias9". Because = they > are processed in alphabetically sorted order. I didn't do anything to = sort > the values, they came pre-sorted in alphabetic order. >=20 > If I simply throw in a "| sort -n", then it will change it to = numerically sorted. > As you might expect, numerically sorting the above list would result = in: >=20 > foo1 > foo2 > foo10 > foo20 >=20 > Trivial really. I'll throw a patch at you when I get some cycles = (soon). Hi Devin, Jason- I've been behind on my mailing list e-mail for a while, but I really = like the idea and the patch proposed here. I don't see anything like it = in head yet, so ... Ping? :) JN >> On Jan 4, 2014, at 5:29, "Teske, Devin" = wrote: >>=20 >>>=20 >>> On Jan 3, 2014, at 10:28 PM, Jason Hellenthal wrote: >>>=20 >>>> Alright something is a little off about this from a running = standpoint it did what it is meant to do. >>>>=20 >>>> Bug1: it seems to have looped back over itself reissuing two = addresses from the top of the list. >>>>=20 >>>> Test case: >>>> I have aliases 0-14 used numbered as such. >>>> Aliases 0-7 are ipv6 >>>> Aliases 8-14 are ipv4 >>>>=20 >>>> I commented out alias 2 and 6 to break up consecutive order. >>>>=20 >>>> Alias 8 & 9 appeared to have been run after alias 14. >>>>=20 >>>>=20 >>>> Something is awry but I can't quite pick out what it is yet. >>>=20 >>>> On Dec 28, 2013, at 23:24, "Teske, Devin" = wrote: >>>>=20 >>>>> On Dec 27, 2013, at 9:53 PM, wrote: >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> I.e.: I would like to achieve this... >>>>>>=20 >>>>>> *_alias[1-99] =3D System type addresses "Importand addresses or = internal" >>>>>> *_alias[100-199] =3D Aliases for interface 1 >>>>>> *_alias[200-299] =3D Aliases for interface 2 >>>>>> etc... >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Looking at _alias'N' sequentialy feels like a neucense. >>>>>=20 >>>>> You mean something like the attached?