netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: "Domsch, Matt" <Matt_Domsch@Dell.com>,
	John Haxby <john.haxby@oracle.com>,
	"net-tools@lina.inka.de" <net-tools@lina.inka.de>,
	Bernd Eckenfels <be-mail2010@lina.inka.de>,
	"K, Narendra" <Narendra_K@Dell.com>,
	"shemminger@linux-foundation.org"
	<shemminger@linux-foundation.org>,
	"netfilter-devel@vger.kernel.org"
	<netfilter-devel@vger.kernel.org>,
	"jgarzik@users.sourceforge.net" <jgarzik@users.sourceforge.net>,
	"Rose, Charles" <Charles_Rose@Dell.com>,
	"Iyer, Shyam" <Shyam_Iyer@Dell.com>,
	"Hargrave, Jordan" <Jordan_Hargrave@Dell.com>,
	"Shandilya, Sandeep K" <Sandeep_K_Shandilya@Dell.com>
Subject: Re: [PROPOSAL]: Alias names for network interfaces
Date: Thu, 14 Jan 2010 09:44:40 +0100	[thread overview]
Message-ID: <4B4ED978.9030700@trash.net> (raw)
In-Reply-To: <alpine.LSU.2.01.1001131908530.18981@obet.zrqbmnf.qr>

Jan Engelhardt wrote:
> On Wednesday 2010-01-13 18:46, Domsch, Matt wrote:
>>> I am less than enthusiastic about the idea as well.  I've come across 
>>> numerous userspace scripts and whatnot that have enough trouble with the 
>>> default route not being through "eth0" let alone anything more 
>>> complex.   Aliases are going to cause a lot of problems for a lot of 
>>> people for little actual gain.
>> The "actual gain" is to provide a deterministic method of naming
>> network devices, in a stateless manner (e.g. w/o hard-coding MAC
>> addresses).  We don't have deterministic naming today.  It only gets
>> worse as we add more NIC ports.
>>
>> The kernel doesn't provide deterministic naming.
>>
>> Renaming from ethN to ethM is racy; often we wind up with devices named
>> 'eth0_rename'.
>>
>> Stephen noted (echoed in Bernd's comment) that the ethN namespace is
>> effectively an ABI (and certainly the 15-character IFNAMESZ is).
>> Userspace tools today expect ethN names.
> 
> Let's get things straight at least. Userspace does not expect eth#.
> You may get away with claiming feature-incompleteness if your program
> has no idea of tun#, sit# gre# and such, but there is also wlan#,
> tap#, and others that are a link/ether device. If a program relies on
> eth#, it is broken and should either be fixed or left dead in its
> corner.

I agree, this is simply broken. iptraf is one of these sad examples
which has been annoying me for years.

  reply	other threads:[~2010-01-14  8:44 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <EDA0A4495861324DA2618B4C45DCB3EE5899AC@blrx3m08.blr.amer.dell.com>
2010-01-12 19:49 ` Re:[PROPOSAL]: Alias names for network interfaces Narendra K
2010-01-13  0:11   ` Jan Engelhardt
2010-01-13  6:47     ` [PROPOSAL]: " Narendra_K
2010-01-13 11:04       ` Bernd Eckenfels
2010-01-13 17:22         ` John Haxby
2010-01-13 17:46           ` Domsch, Matt
2010-01-13 18:11             ` Bernd Eckenfels
2010-01-13 18:21             ` Jan Engelhardt
2010-01-14  8:44               ` Patrick McHardy [this message]
2010-01-14  9:35                 ` Jan Engelhardt
2010-01-15 19:14               ` Narendra_K
2010-01-18 17:07                 ` Marco Innocenti
2010-01-19 17:32                   ` Narendra_K
2010-01-19 22:31                     ` Stephen Hemminger
2010-01-20  1:02                       ` Bernd Eckenfels
2010-01-20 16:42                       ` Narendra_K
2010-01-13 17:54           ` Stephen Hemminger
2010-01-13 13:24   ` Patrick McHardy
2010-01-13 13:43     ` Jan Engelhardt
2010-01-13 16:27       ` Stephen Hemminger
2010-01-13 17:00         ` Narendra_K
2010-01-14  8:41           ` Patrick McHardy
2009-12-17 13:54 Narendra_K
2009-12-17 14:48 ` Jan Engelhardt
2009-12-18  2:02   ` Bernd Eckenfels
2009-12-18 13:19     ` Narendra_K
2009-12-18 13:42       ` Jan Engelhardt
2009-12-18 14:02         ` Domsch, Matt
2009-12-18 14:08         ` Domsch, Matt
2009-12-18 14:15           ` Jan Engelhardt
2009-12-20  0:12             ` Jordan_Hargrave
2009-12-18 17:38       ` Stephen Hemminger
2009-12-21 17:28         ` Narendra_K
2009-12-21 17:36           ` Stephen Hemminger
2009-12-23 17:11             ` Narendra_K

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B4ED978.9030700@trash.net \
    --to=kaber@trash.net \
    --cc=Charles_Rose@Dell.com \
    --cc=Jordan_Hargrave@Dell.com \
    --cc=Matt_Domsch@Dell.com \
    --cc=Narendra_K@Dell.com \
    --cc=Sandeep_K_Shandilya@Dell.com \
    --cc=Shyam_Iyer@Dell.com \
    --cc=be-mail2010@lina.inka.de \
    --cc=jengelh@medozas.de \
    --cc=jgarzik@users.sourceforge.net \
    --cc=john.haxby@oracle.com \
    --cc=net-tools@lina.inka.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=shemminger@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).