netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@linux-foundation.org>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: Patrick McHardy <kaber@trash.net>,
	Narendra K <Narendra_K@dell.com>,
	be-mail2009@lina.inka.de, net-tools@lina.inka.de,
	netfilter-devel@vger.kernel.org, jgarzik@users.sourceforge.net,
	charles_rose@dell.com, matt_domsch@dell.com, shyam_iyer@dell.com,
	jordan_hargrave@dell.com, sandeep_k_shandilya@dell.com
Subject: Re: [PROPOSAL]: Alias names for network interfaces
Date: Wed, 13 Jan 2010 08:27:11 -0800	[thread overview]
Message-ID: <20100113082711.2dee7415@nehalam> (raw)
In-Reply-To: <alpine.LSU.2.01.1001131439330.31436@obet.zrqbmnf.qr>

On Wed, 13 Jan 2010 14:43:26 +0100 (CET)
Jan Engelhardt <jengelh@medozas.de> wrote:

> 
> On Wednesday 2010-01-13 14:24, Patrick McHardy wrote:
> >> 
> >> The proposal is to enhance iptables (and other tools which might fail if
> >> integrated port 1 does not get named as eth0) to support something like
> >[...]
> >> +	strcpy(vianame, kernel_name);
> >> +	int vialen = strlen(kernel_name);
> >>  	if ((vialen == 0) || (vialen == 1 && vianame[0] == '+'))
> >>  		memset(mask, 0, IFNAMSIZ);
> >>  	else if (vianame[vialen - 1] == '+') {
> >> 
> >> 
> >> where kernel_name is the ethN name that will be returned by a library
> >> like libnetdevname which will map the user supplied "Embedded_NIC_1"
> >> name to the corresponding ethN name, thus bringing in determinism while
> >> referring to the network interfaces.
> >> 
> >> Netfilter-devel, would this be acceptable ?
> >
> >What I don't like very much is that you can't decide whether to
> >map the interface names back in order to display a rule the same
> >way it was specified. Anyone looking at the output will have to
> >know the alias mapping, which seems to defeat the purpose of
> >this patch.
> 
> By definition, the mapping from aliases to real names is not
> bijective, thus not always unambiguously reversible. That also means
> there will be problems if either side of a mapping disappears - say,
> across a reboot - you are in for some local DoS. That of course also
> holds for regular network interface names, but only if you do not use
> udev to give them a persistent name.

Is there a tool to do:
   netdevtoalias eth0
and
   netdevfromalias Embedded_NIC_1



-- 

  reply	other threads:[~2010-01-13 16:28 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
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 [this message]
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=20100113082711.2dee7415@nehalam \
    --to=shemminger@linux-foundation.org \
    --cc=Narendra_K@dell.com \
    --cc=be-mail2009@lina.inka.de \
    --cc=charles_rose@dell.com \
    --cc=jengelh@medozas.de \
    --cc=jgarzik@users.sourceforge.net \
    --cc=jordan_hargrave@dell.com \
    --cc=kaber@trash.net \
    --cc=matt_domsch@dell.com \
    --cc=net-tools@lina.inka.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=sandeep_k_shandilya@dell.com \
    --cc=shyam_iyer@dell.com \
    /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).