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
| ||
|
Message-ID: <20091106231716.GJ29251@ldl.fc.hp.com> Date: Fri, 6 Nov 2009 16:17:16 -0700 From: dann frazier <dannf@...com> To: Matt Domsch <Matt_Domsch@...l.com>, Narendra_K@...l.com, bryan@...zban.is-a-geek.net, 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 Fri, Nov 06, 2009 at 11:35:24PM +0100, Marco d'Itri wrote: > On Nov 06, Matt Domsch <Matt_Domsch@...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. This seems to me like a good installer feature - give the user an option to enter a name for an interface, with the default option to use the eth* names. To illustrate by example, I imagine an installer flow that looks like this: [Do Hardware Discovery] [Automatically reorder kernel names for reasonable defaults; eth0-eth{n-1} map to n onboard nics] Sample user interface for network configuration: ------------Choose an interface to configure -------------- | Multiple unconfigured interfaces detected. | | Select an interface to configure by: | | 1. Kernel name (eth0, eth1, etc) | | 2. Mac Address | | 3. Chassis name | | 4. PCI Slot | ----------------------------------------------------------- ----Choose an interface to configure (by chassis name)----- | 1. LOM0 | | 2. LOM1 | | 3. Undefined | | 4. Undefined | ----------------------------------------------------------- ----------------Name interface - (chassis name LOM0)------- | Name to use for this interface [eth0]: __mynet0_ | ----------------------------------------------------------- ----------------------------------------------------------- | Configure interface - mynet0 | | 1. DHCP | | 2. Static | | ... | ----------------------------------------------------------- [Generate udev rules that bind the user-selected name to the user-selected attribute] -- 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