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-136297-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1S7blq-0002dP-Hv
for garchives@archives.gentoo.org; Wed, 14 Mar 2012 00:08:50 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id ADDC1E0D61;
Wed, 14 Mar 2012 00:08:36 +0000 (UTC)
Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52])
by pigeon.gentoo.org (Postfix) with ESMTP id 11349E0D4B
for <gentoo-user@lists.gentoo.org>; Wed, 14 Mar 2012 00:07:32 +0000 (UTC)
Received: by dadp12 with SMTP id p12so1774988dad.11
for <gentoo-user@lists.gentoo.org>; Tue, 13 Mar 2012 17:07:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type:content-transfer-encoding;
bh=oA9EUjyuVnuFxSUt8x2h8fYKzcq2iCarvdauMlZUKnY=;
b=bs5wJb6o3q4WrvxeqevaeiGZfyKKHMe3DolPhD8QRbEDA4YgHG7qrXavUWNEhpAFbE
SjcG2oQsYcFXLdWPX932LIo02t3gLxRa1FM4w2LtrFagip3AHzq2b7W4xXMpOuoQva8/
crh7rH3WLpqK5h5oifTcM5XXCCYWH66GcbJzvplz7arMjnuCAEBqlrBJ3tL4woLhcdI5
8RwO3HYWHz88Rb7Fc4EGMUy8SQT7AOeAcER98vtByZ3IxbSsdLmsiOW5mXm+fZ56mVZ9
D2hpCXGg1HvtYWovY3HQ+gJUMbaL7J5hP1NKr/ZpPOjvQnKAc+HBhXHkfBBhLlg/ZI1G
xlgg==
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.68.225.39 with SMTP id rh7mr822822pbc.104.1331683652315; Tue,
13 Mar 2012 17:07:32 -0700 (PDT)
Received: by 10.68.197.41 with HTTP; Tue, 13 Mar 2012 17:07:32 -0700 (PDT)
In-Reply-To: <20120313230358.GF2536@acm.acm>
References: <20120312092432.GA2959@acm.acm>
<20120313073306.GC23544@waltdnes.org>
<20120313130534.GB3457@acm.acm>
<20120313190052.GA2430@waltdnes.org>
<20120313194727.GB2536@acm.acm>
<CADPrc83mmaeybgdEb0phBrp=fBcF3EWkpZawp0Mo8wpvDje5NQ@mail.gmail.com>
<20120313210737.GD2536@acm.acm>
<20120313213330.78c5ebf7@digimed.co.uk>
<20120313222019.GE2536@acm.acm>
<CADPrc82SPiqxmKMf5aVGZtaXG6d_X17S6AWbx=pjnJKLTZJM-A@mail.gmail.com>
<20120313230358.GF2536@acm.acm>
Date: Tue, 13 Mar 2012 18:07:32 -0600
Message-ID: <CADPrc80ejwk+DqysM3K-fmsjBgybfZjrHeYKHEoJ+bMigCg6HQ@mail.gmail.com>
Subject: Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version
5 - failure :-(
From: =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw6lz?= <caneko@gmail.com>
To: gentoo-user@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 5cb3ee0c-c715-4d31-972f-2e7182d0add3
X-Archives-Hash: 406b26759cdc470583e03914a76287ce
On Tue, Mar 13, 2012 at 5:03 PM, Alan Mackenzie <acm@muc.de> wrote:
> On Tue, Mar 13, 2012 at 04:38:08PM -0600, Canek Pel=C3=A1ez Vald=C3=A9s w=
rote:
>> On Tue, Mar 13, 2012 at 4:20 PM, Alan Mackenzie <acm@muc.de> wrote:
>> > Hello, Neil.
>
>> > On Tue, Mar 13, 2012 at 09:33:30PM +0000, Neil Bothwick wrote:
>> >> On Tue, 13 Mar 2012 21:07:37 +0000, Alan Mackenzie wrote:
>
>> >> > But I really meant what functionality udev has that mdev lacks. =C2=
=A0For
>> >> > example, mdev this morning recognised my USB stick being inserted, =
and
>> >> > created /dev/sdc for it.
>
>> >> udev does a *lot* more than that, for example the persistent naming o=
f
>> >> network interfaces. More significantly, it can run programs based on
>> >> device rules.
>
>> > This is where I start getting unhappy. =C2=A0Is there any need for thi=
s
>> > blurring? =C2=A0Having device nodes is essential to a linux system, an=
d
>> > some programs use these nodes. =C2=A0Why must they be mashed together =
into a
>> > tasteless mush? =C2=A0Is there some advantage to this I haven't twigge=
d yet?
>
>> >> For example, usb_modeswitch installs a udev rule to switch a 3G USB
>> >> modem from CD to modem mode, without which it won't work.
>
>> > Same question as above: why does that switching have to be done via th=
e
>> > device node system rather than via the driver. =C2=A0Isn't that what d=
rivers
>> > are for?
>
>> >> That's fine when you plug it into a running system, but when you boot
>> >> with it plugged in, it can trip over itself because the usb_modeswitc=
h
>> >> executable is in /usr/sbin.
>
>> > Er, that's a different discussion altogether. =C2=A0;-)
>
>> >> You could use this to argue that /usr should be mounted before udev i=
s
>> >> started, but you could just as well use it to argue that udev should =
not
>> >> be trying to run such rules at the boot runlevel.
>
>> > Or that udev shouldn't have "rules". =C2=A0I still don't understand th=
e basic
>> > concept driving this thing. =C2=A0My HDDs don't need rules - they just=
need a
>> > mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate
>> > drivers built into my kernel.
>
>> > Am I being stupid? =C2=A0Despite your example above, I still don't see=
what
>> > udev is about, why it's necessary, or even why it's advantageous.
>
>> IMHO, the thing that most people are missing is the fact that neither
>> udev nor Linux "got complicated". The computing world itself "got
>> complicated".
>
> Not really. =C2=A0It's been getting more complicated since long before I
> starting working in it in 1980. =C2=A0Nothing's changed there.
>
>> We have Linux running in the same beige machines it has been running
>> since 1991, but it also runs in TVs, tablets, cellphones, fridges,
>> cars, ebook readers, and (soon enough, I'm sure) the kitchen sink.
>> This devices behave very differently from our old and beloved beige
>> boxen.
>
> Not at the level of needing device nodes under /dev and drivers connected
> to them, they haven't.
>
>> They need to handle lots of different hardware comming and going, via
>> USB, Firewire, Bluetooth, WIMAX, and who knows what else in the future.
>
> Yes. =C2=A0That's why there's a generic facility for building arbitrary
> drivers into a kernel. =C2=A0That's not new either.
>
>> The principal idea behind udev, is that we *don't* kown (we *can't*
>> know) what hardware this or that machine is gonna have at some point.
>> And we want the machine (and the new hardware) to "just work" when
>> they are connected.
>
> Huh? =C2=A0What's that to do with udev? =C2=A0You're talking at far too h=
igh a
> level of abstraction. =C2=A0The new hardware will "just work" if there ar=
e the
> correct drivers built in. =C2=A0That's as true of udev as it is of mdev a=
s it
> is of the old static /dev with mknod.
No, it is not. You are letting out the sine qua non of the matter: the
device has to be built, *and the /dev file should exists*. I hope you
are not suggesting that we put *ALL* the possible files under /dev,
because that was the idea before devfs, and it doesn't work *IN
GENERAL*.
So, you need something to handle device files on /dev, so you don't
need every possible device file for every possible piece of hardware.
But then you want to handle the same device with the same device name,
so you need some kind of database. Then for the majority of users,
they want to see *something* happen when they connect aa piece of
hardware to their computers. So you need to handle the events
associated with the connections (or discovery, for things like
Bluetooth) of the devices, and since udev is already handling the
database and the detection of connections/discovery, I agree with the
decision of leting udev to execute programs when something gets
connected. You could get that function in another program, but you are
only moving the problem, *and it can also happen very early at boot
time*, so lets udev handle it all the time.
I hope you see where I'm going. As I said before, mdev could (in
theory) do the same that udev does. But then it will be as complicated
as udev, *because it is a complicated problem* in general. And I again
use my fuel injection analogy: it is not *necessary*. It is just very
damn convenient.
> [ .... ]
>
>> So, yeah, it's more complicated. The world got complicate; better get
>> used to it.
>
> You're bluffing, aren't you? =C2=A0You really don't have any more idea th=
an I
> do about the technical motivation for udev, do you?
I'm not, and I have a really time understanding why you don't see the
complexity on the problem. I explained above: it is a complicated
problem (when dealing with the general case), and therefore the
(general) solution is bound to be also complicated.
You want it simple? Tha'ts fine, it is possible. It's just that it
will not solve the general problem, just a very specific subset of it.
Just as mdev is doing; Walt just posted an email explaining that if
you use GNOME, KDE, XFCE, or LVM2, mdev is not for you.
I will not be surprised if in the future the list of programs "not for
mdev" only grows.
Regards.
--=20
Canek Pel=C3=A1ez Vald=C3=A9s
Posgrado en Ciencia e Ingenier=C3=ADa de la Computaci=C3=B3n
Universidad Nacional Aut=C3=B3noma de M=C3=A9xico