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). |