Gentoo Archives: gentoo-user

From: Alan Mackenzie <acm@×××.de>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(
Date: Tue, 13 Mar 2012 23:06:37
Message-Id: 20120313230358.GF2536@acm.acm
In Reply to: Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-( by "Canek Peláez Valdés"
1 On Tue, Mar 13, 2012 at 04:38:08PM -0600, Canek Peláez Valdés wrote:
2 > On Tue, Mar 13, 2012 at 4:20 PM, Alan Mackenzie <acm@×××.de> wrote:
3 > > Hello, Neil.
4
5 > > On Tue, Mar 13, 2012 at 09:33:30PM +0000, Neil Bothwick wrote:
6 > >> On Tue, 13 Mar 2012 21:07:37 +0000, Alan Mackenzie wrote:
7
8 > >> > But I really meant what functionality udev has that mdev lacks.  For
9 > >> > example, mdev this morning recognised my USB stick being inserted, and
10 > >> > created /dev/sdc for it.
11
12 > >> udev does a *lot* more than that, for example the persistent naming of
13 > >> network interfaces. More significantly, it can run programs based on
14 > >> device rules.
15
16 > > This is where I start getting unhappy.  Is there any need for this
17 > > blurring?  Having device nodes is essential to a linux system, and
18 > > some programs use these nodes.  Why must they be mashed together into a
19 > > tasteless mush?  Is there some advantage to this I haven't twigged yet?
20
21 > >> For example, usb_modeswitch installs a udev rule to switch a 3G USB
22 > >> modem from CD to modem mode, without which it won't work.
23
24 > > Same question as above: why does that switching have to be done via the
25 > > device node system rather than via the driver.  Isn't that what drivers
26 > > are for?
27
28 > >> That's fine when you plug it into a running system, but when you boot
29 > >> with it plugged in, it can trip over itself because the usb_modeswitch
30 > >> executable is in /usr/sbin.
31
32 > > Er, that's a different discussion altogether.  ;-)
33
34 > >> You could use this to argue that /usr should be mounted before udev is
35 > >> started, but you could just as well use it to argue that udev should not
36 > >> be trying to run such rules at the boot runlevel.
37
38 > > Or that udev shouldn't have "rules".  I still don't understand the basic
39 > > concept driving this thing.  My HDDs don't need rules - they just need a
40 > > mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate
41 > > drivers built into my kernel.
42
43 > > Am I being stupid?  Despite your example above, I still don't see what
44 > > udev is about, why it's necessary, or even why it's advantageous.
45
46 > IMHO, the thing that most people are missing is the fact that neither
47 > udev nor Linux "got complicated". The computing world itself "got
48 > complicated".
49
50 Not really. It's been getting more complicated since long before I
51 starting working in it in 1980. Nothing's changed there.
52
53 > We have Linux running in the same beige machines it has been running
54 > since 1991, but it also runs in TVs, tablets, cellphones, fridges,
55 > cars, ebook readers, and (soon enough, I'm sure) the kitchen sink.
56 > This devices behave very differently from our old and beloved beige
57 > boxen.
58
59 Not at the level of needing device nodes under /dev and drivers connected
60 to them, they haven't.
61
62 > They need to handle lots of different hardware comming and going, via
63 > USB, Firewire, Bluetooth, WIMAX, and who knows what else in the future.
64
65 Yes. That's why there's a generic facility for building arbitrary
66 drivers into a kernel. That's not new either.
67
68 > The principal idea behind udev, is that we *don't* kown (we *can't*
69 > know) what hardware this or that machine is gonna have at some point.
70 > And we want the machine (and the new hardware) to "just work" when
71 > they are connected.
72
73 Huh? What's that to do with udev? You're talking at far too high a
74 level of abstraction. The new hardware will "just work" if there are the
75 correct drivers built in. That's as true of udev as it is of mdev as it
76 is of the old static /dev with mknod.
77
78 [ .... ]
79
80 > So, yeah, it's more complicated. The world got complicate; better get
81 > used to it.
82
83 You're bluffing, aren't you? You really don't have any more idea than I
84 do about the technical motivation for udev, do you?
85
86 > Regards.
87 > --
88 > Canek Peláez Valdés
89 > Posgrado en Ciencia e Ingeniería de la Computación
90 > Universidad Nacional Autónoma de México
91
92 --
93 Alan Mackenzie (Nuremberg, Germany).

Replies