From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-146322-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 9585F138010
for <garchives@archives.gentoo.org>; Sun, 31 Mar 2013 11:48:56 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 51FB3E093A;
Sun, 31 Mar 2013 11:48:48 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
(using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id EBAE5E08FB
for <gentoo-user@lists.gentoo.org>; Sun, 31 Mar 2013 11:48:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp.gentoo.org (Postfix) with ESMTP id D783E33BF4E
for <gentoo-user@lists.gentoo.org>; Sun, 31 Mar 2013 11:48:45 +0000 (UTC)
X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org
X-Spam-Flag: NO
X-Spam-Score: -0.891
X-Spam-Level:
X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5.5
tests=[AWL=0.455, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.344,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable
Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1])
by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id OlnV4qd7NbNC for <gentoo-user@lists.gentoo.org>;
Sun, 31 Mar 2013 11:48:38 +0000 (UTC)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3])
(using TLSv1 with cipher AES256-SHA (256/256 bits))
(No client certificate requested)
by smtp.gentoo.org (Postfix) with ESMTPS id 5566733DB12
for <gentoo-user@gentoo.org>; Sun, 31 Mar 2013 11:48:36 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <lnx-gentoo-user@m.gmane.org>)
id 1UMGkq-0005Az-N9
for gentoo-user@gentoo.org; Sun, 31 Mar 2013 13:48:56 +0200
Received: from rej5.kyla.fi ([82.130.49.149])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-user@gentoo.org>; Sun, 31 Mar 2013 13:48:56 +0200
Received: from nunojsilva by rej5.kyla.fi with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-user@gentoo.org>; Sun, 31 Mar 2013 13:48:56 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: gentoo-user@lists.gentoo.org
From: "Nuno J. Silva (aka njsg)" <nunojsilva@ist.utl.pt>
Subject: [gentoo-user] Re: Udev update and persistent net rules changes
Date: Sun, 31 Mar 2013 11:48:19 +0000 (UTC)
Message-ID: <kj97q3$8t2$1@ger.gmane.org>
References: <515701AE.9010509@libertytrek.org> <kj93gf$50v$1@ger.gmane.org>
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: rej5.kyla.fi
User-Agent: slrn/pre1.0.0-18 (Linux)
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
X-Archives-Salt: f997d82d-8766-4cb2-9752-7880ae49d919
X-Archives-Hash: e41d79ede433695f0773321f9be0670c
On 2013-03-31, Nikos Chantziaras <realnc@gmail.com> wrote:
> On 30/03/13 17:15, Tanstaafl wrote:
>> Ok, just read the new news item and the linked udev-guide wiki page
>
> You should probably also read:
>
> http://blog.flameeyes.eu/2013/03/predictably-non-persistent-names
>
> and:
>
>
> http://blog.flameeyes.eu/2013/03/predictable-persistently-non-mnemonic-names
The feeling that I got while reading the first was exactly what the
second talks about.
We - from what I understand - had scripts automatically generating the
name rules from MAC addresses, it's just that they generated stuff like
ethX.
Can't we just keep these scripts around (even if this was something
provided by upstream and we would have to forge a new incarnation)?
I mean, IMHO, net0, wl0, ... are much easier to deal with and understand
than something physically-based. They also avoid problems caused by
moving these cards around, or changes in the kernel drivers or BIOS, or
BIOS settings that eventually end up exposing cards in a different way.
The problem with the old approach was *just* the name clash that
rendered the hacky approach unreliable. Maybe we could just fix the
issue by using non-clashing namespaces, instead of pushing a completely
different (and possibly less reliable) naming scheme by default.
--
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/