network.subr _aliasN handling

Sat Feb 22 01:13:54 UTC 2014

> -----Original Message-----
> From: John Nielsen [mailto:lists at jnielsen.net]
> Sent: Friday, February 21, 2014 9:06 AM
> To: Devin Teske
> Cc: Jason Hellenthal; rc at freebsd.org; net at freebsd.org
> Subject: Re: network.subr _aliasN handling
> 
> On Jan 4, 2014, at 4:25 AM, Teske, Devin <Devin.Teske at fisglobal.com>
wrote:
> 
> > On Jan 4, 2014, at 2:59 AM, Jason Hellenthal wrote:
> >
> >> 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.
> >
> > It's not as scary as it sounds.
> >
> > The issue is that the variables are sorted alphabetically, instead of
> > numerically.
> >
> > Let's take four words: foo1, foo2, foo10, and foo20.
> > If you sort them alphabetically, you get:
> >
> > 	foo1
> > 	foo10
> > 	foo2
> > 	foo20
> >
> > You'll notice this when doing a directory listing, as that too is
> > sorted alphabetically.
> >
> > 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.
> >
> > 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:
> >
> > 	foo1
> > 	foo2
> > 	foo10
> > 	foo20
> >
> > 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
> 
[Devin Teske] 

Hi JN, here's a new patch that incorporates numerical sorting as well as
what
the original patch set out to do ... make "gaps" possible (so that you could
comment out an alias without having to renumber all the ones following).

Give it a look, let me know what you think.
-- 
Devin

NB: Below for context only.

> >> On Jan 4, 2014, at 5:29, "Teske, Devin" <Devin.Teske at fisglobal.com>
wrote:
> >>
> >>>
> >>> On Jan 3, 2014, at 10:28 PM, Jason Hellenthal wrote:
> >>>
> >>>> Alright something is a little off about this from a running
standpoint it did
> what it is meant to do.
> >>>>
> >>>> Bug1: it seems to have looped back over itself reissuing two
addresses
> from the top of the list.
> >>>>
> >>>> Test case:
> >>>> I have aliases 0-14 used numbered as such.
> >>>> Aliases 0-7 are ipv6
> >>>> Aliases 8-14 are ipv4
> >>>>
> >>>> I commented out alias 2 and 6 to break up consecutive order.
> >>>>
> >>>> Alias 8 & 9 appeared to have been run after alias 14.
> >>>>
> >>>>
> >>>> Something is awry but I can't quite pick out what it is yet.
> >>>
> >>>> On Dec 28, 2013, at 23:24, "Teske, Devin" <Devin.Teske at fisglobal.com>
> wrote:
> >>>>
> >>>>> On Dec 27, 2013, at 9:53 PM, <jhellenthal at dataix.net> wrote:
> >>>>>
> >>>>>> 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.
> >>>>>
> >>>>> You mean something like the attached?
> 
> _______________________________________________
> freebsd-rc at freebsd.org mailing list
>
https://urldefense.proofpoint.com/v1/url?u=http://lists.freebsd.org/mailman/
lis
> tinfo/freebsd-
> rc&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHD
> ubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=a%2FXSurQc9zrgW0CMePYdCc
> aPq2wsx%2FFfMyb4Wfq6%2B1g%3D%0A&s=7592611709212c7674b7be5b549a
> fc9e19012de4ed100174b8a719795614d131
> To unsubscribe, send any mail to "freebsd-rc-unsubscribe at freebsd.org"

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.