From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-user+bounces-133428-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1Rissv-0005gv-CW
for garchives@archives.gentoo.org; Thu, 05 Jan 2012 19:21:57 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 814B321C265;
Thu, 5 Jan 2012 19:21:43 +0000 (UTC)
Received: from mail-ey0-f181.google.com (mail-ey0-f181.google.com [209.85.215.181])
by pigeon.gentoo.org (Postfix) with ESMTP id 4218E21C255
for <gentoo-user@lists.gentoo.org>; Thu, 5 Jan 2012 19:20:21 +0000 (UTC)
Received: by eaai1 with SMTP id i1so680274eaa.40
for <gentoo-user@lists.gentoo.org>; Thu, 05 Jan 2012 11:20:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type:content-transfer-encoding;
bh=d4XiFZvwt8WadaEngFvwftiLad/8AATKAs1U5yj9w/s=;
b=MUAAIqQuBQ/2QqTCOdxyVLxkCQLt3/hb2lbaYsdeBWwQaimkHqa3tuky4zZp8rEX0w
In1iNYbIIEXsac+9+MTd4eVJO0L9eimx2PHy0I5gsWNR+Yf++eksRLjLqbwTzx6gDlEm
yh3piBLHnNnQUqJtL/A6ZsXPrdndLf5c8vXfM=
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
MIME-Version: 1.0
Received: by 10.204.133.207 with SMTP id g15mr1356121bkt.17.1325791221467;
Thu, 05 Jan 2012 11:20:21 -0800 (PST)
Received: by 10.204.177.18 with HTTP; Thu, 5 Jan 2012 11:20:21 -0800 (PST)
In-Reply-To: <20120105100149.GA2443@nicolas-desktop>
References: <20120103123209.GB2410@nicolas-desktop>
<CAA2qdGX-Hubx0QzsRJSkwJtTqGcSpNADi=4s52_RbPOremSCLw@mail.gmail.com>
<20120103131346.GC2410@nicolas-desktop>
<CAA2qdGXWWZe_xVWWKAWAcfwhaQ9MxOfat0PDzCbiedRXvYd-kw@mail.gmail.com>
<20120103143120.GF2410@nicolas-desktop>
<20120103221555.22c778a3@digimed.co.uk>
<4F038C23.5030708@gmail.com>
<CAA2qdGVPag6XWU_vUDzk5dkX3YrcdHNnDgLB7qp+7Th7NhfAtg@mail.gmail.com>
<CADPrc81YiGs3sEptADAUHjBxmY6ANz-G3Gu8JwjzO=16DULUqA@mail.gmail.com>
<CAA2qdGXzhZQzNCH8RgQK=2bbW0cJXMy3SdZb+ZJMhi7TaBEf2A@mail.gmail.com>
<20120105100149.GA2443@nicolas-desktop>
Date: Thu, 5 Jan 2012 14:20:21 -0500
Message-ID: <CA+czFiDcHtK7ow_wsPNoFwcMNsp-a7wXExUzWBaiRE6AyzUjTg@mail.gmail.com>
Subject: Re: [gentoo-user] Re: Beta test Gentoo with mdev instead of udev;
version 3
From: Michael Mol <mikemol@gmail.com>
To: gentoo-user@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 415918b5-5015-46da-baa9-e2599c9fb69e
X-Archives-Hash: f5d207936d79094d1bc4b4791f41bb72
On Thu, Jan 5, 2012 at 5:01 AM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote=
:
> The 05/01/12, Pandu Poluan wrote:
>
>> And mdev might be a 'toy' to you, but embedded Linux developers will
>> vehemently disagree with you.
>>
>> And based on the responses in this thread, server guys will also
>> disagree with you.
>
> On the embedded side, we need udev much more than you think to support
> bluetooth, tablet and so. Android uses udev. This is even more true when
> we know that users will expect to have any plugged-in devices at
> whatever boot time or runing system be working out of the box. BTW, this
> is not a major problem since embedded devices already often use initramfs=
.
>
> On servers, I wouldn't be surprised that hypervisor tools will expect
> /dev/cdrom instead of /dev/sr0.
> AFAIK, mdev doesn't provide persistent device names and changing a
> ethernet card might result in a highly broken system where udev will let
> all interfaces working but the changed one. =C2=A0Worse, I think mdev mig=
ht
> change of device names upon reboot so that all ethernet devices can be
> mixed up in ways like eth0 -> eth1, eth1 -> eth3 and eth2 -> eth0.
FWIW, I had a /dev/cdrom symlink long before *devfs* even existed, let
alone udev.
Also, ethN numberings are generally stable until and unless you do
some strange BIOS tweaking or hardware changes, and should be able to
be stabilized in the event the instability comes from some racy module
loading mechanism.
udev's attempts at stabilizing network interfaces have made things
worse more often than I've heard of it making them better. Hit any
search engine for "eth0 missing 70-persistent-net.rules".
(Apologies for anyone who sees this message in such a result; just
delete /etc/udev/rules.d/70-persistent-net.rules, and you should get
eth0 back.)
--=20
:wq