[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 22 Jul 2014 09:45:20 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Re: if_nameindex, etc. [Re: Progress towards 1.1.4]
On Tue, Jul 22, 2014 at 10:58:43AM +0200, Natanael Copa wrote:
> On Mon, 21 Jul 2014 12:13:42 -0400
> Rich Felker <dalias@...c.org> wrote:
>
> > On Mon, Jul 21, 2014 at 07:09:56PM +0300, Timo Teras wrote:
> > > So +300 bytes in text, but in return there is added functionality such
> > > as returning the link-level info in PF_PACKET dump (including
> > > statistics). I also expect the code to be a lot faster:
> >
> > One thing I forgot to ask: is there any regression in returning
> > old-style interface "alias" names, i.e. do things like "eth0:1" still
> > appear in the output of if_nameindex?
>
> Maybe this is an opportunity to get rid of the interface "alias"? it
> was a hack to make it possible to assign multiple addresses on a single
> NIC.
>
> Do we need support that kind of legacy?
This is actually one of the few legacy features I somewhat want -- for
being able to do most simple configurations with just ifconfig.
Regardless of whether I want it or not though, it's more a matter of
presenting complete and consistent results. If we suppressed aliases
we'd either need to fake the address as being on the main interface
name (which might confuse tools working with both) or omit them
completely (which would obviously be bad).
I think if you do want to deprecate these aliases, the right place to
do it is in the kernel, so that the state can't exist to begin with,
rather than having libc try to hide it/pretend it doesn't exist.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
