lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 10 Nov 2009 09:23:28 -0800
From:	Stephen Hemminger <shemminger@...tta.com>
To:	<Narendra_K@...l.com>
Cc:	<md@...ux.IT>, <Matt_Domsch@...l.com>,
	<bryan@...zban.is-a-geek.net>, <dannf@...com>,
	<bhutchings@...arflare.com>, <netdev@...r.kernel.org>,
	<linux-hotplug@...r.kernel.org>, <Jordan_Hargrave@...l.com>,
	<Charles_Rose@...l.com>, <Sandeep_K_Shandilya@...l.com>
Subject: Re: PATCH: Network Device Naming mechanism and policy

On Mon, 9 Nov 2009 20:11:47 +0530
<Narendra_K@...l.com> wrote:

> 
> >> > As a distribution developer I highly value solutions like 
> >this which 
> >> > do not require patching every application which deals with 
> >interface 
> >> > names and then teaching users about aliases which only 
> >work in some 
> >> > places and are unknown to the kernel.
> >> Fair enough - but would you object if we changed the naming scheme 
> >> from eth%d to something else?
> >I suppose that this would depend on what else. :-) Since you 
> >want radical changes I recommend that you design the new 
> >persistent naming infrastructure in a way that will allow root 
> >to choose to use the classic naming scheme, or many users will 
> >scream a lot and at least some distributions will do it anyway.
> >I also expect that providing choice at the beginning of 
> >development may lead to more acceptance later if and when the 
> >new scheme will have proved itself to be superior (at least in 
> >some situations).
> >You have tought about this for a long time and if so far you 
> >have not found a solution which is widely considered superior 
> >then I doubt that one will appear soon. Providing your 
> >favourite naming scheme as an optional add on will immediately 
> >benefit those who like it and greatly reduce opposition from 
> >those who do not.
> 
> In that way, I suppose char device node solution fits the scheme
> perfectly. It doesn't change or interfere with the kernel's default
> naming scheme (ethN) in any way. Also, the applications continue to work
> the way they did and in addition to supporting traditional names, they
> would also support pathnames. Whether all the user space applications
> need to be patched can be discussed and debated. But, we can patch
> applications like, installers and firewall code, which when don't see
> determinism ("eth0 mapping to integrated port 1"), fail and cause very
> high impact could be patched. Since users are already familiar with
> pathnames like /dev/disk/by-id{label, uuid}, I suppose it might not be
> very difficult to get used to pathnames like
> /dev/netdev/by-chassis-label/Embedded_NIC_1. Would that be acceptable ?
>

IFNAMSIZ = 16 is hardwired as part of the kernel binary user space API.

Have you observed that the only developers arguing for this come from
outside the normal circle of networking? It seems to be favored only
by those who come to networking from a system or disk point of view.

-- 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists