1 |
On Tue, Mar 13, 2012 at 5:03 PM, Alan Mackenzie <acm@×××.de> wrote: |
2 |
> On Tue, Mar 13, 2012 at 04:38:08PM -0600, Canek Peláez Valdés wrote: |
3 |
>> On Tue, Mar 13, 2012 at 4:20 PM, Alan Mackenzie <acm@×××.de> wrote: |
4 |
>> > Hello, Neil. |
5 |
> |
6 |
>> > On Tue, Mar 13, 2012 at 09:33:30PM +0000, Neil Bothwick wrote: |
7 |
>> >> On Tue, 13 Mar 2012 21:07:37 +0000, Alan Mackenzie wrote: |
8 |
> |
9 |
>> >> > But I really meant what functionality udev has that mdev lacks. For |
10 |
>> >> > example, mdev this morning recognised my USB stick being inserted, and |
11 |
>> >> > created /dev/sdc for it. |
12 |
> |
13 |
>> >> udev does a *lot* more than that, for example the persistent naming of |
14 |
>> >> network interfaces. More significantly, it can run programs based on |
15 |
>> >> device rules. |
16 |
> |
17 |
>> > This is where I start getting unhappy. Is there any need for this |
18 |
>> > blurring? Having device nodes is essential to a linux system, and |
19 |
>> > some programs use these nodes. Why must they be mashed together into a |
20 |
>> > tasteless mush? Is there some advantage to this I haven't twigged yet? |
21 |
> |
22 |
>> >> For example, usb_modeswitch installs a udev rule to switch a 3G USB |
23 |
>> >> modem from CD to modem mode, without which it won't work. |
24 |
> |
25 |
>> > Same question as above: why does that switching have to be done via the |
26 |
>> > device node system rather than via the driver. Isn't that what drivers |
27 |
>> > are for? |
28 |
> |
29 |
>> >> That's fine when you plug it into a running system, but when you boot |
30 |
>> >> with it plugged in, it can trip over itself because the usb_modeswitch |
31 |
>> >> executable is in /usr/sbin. |
32 |
> |
33 |
>> > Er, that's a different discussion altogether. ;-) |
34 |
> |
35 |
>> >> You could use this to argue that /usr should be mounted before udev is |
36 |
>> >> started, but you could just as well use it to argue that udev should not |
37 |
>> >> be trying to run such rules at the boot runlevel. |
38 |
> |
39 |
>> > Or that udev shouldn't have "rules". I still don't understand the basic |
40 |
>> > concept driving this thing. My HDDs don't need rules - they just need a |
41 |
>> > mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate |
42 |
>> > drivers built into my kernel. |
43 |
> |
44 |
>> > Am I being stupid? Despite your example above, I still don't see what |
45 |
>> > udev is about, why it's necessary, or even why it's advantageous. |
46 |
> |
47 |
>> IMHO, the thing that most people are missing is the fact that neither |
48 |
>> udev nor Linux "got complicated". The computing world itself "got |
49 |
>> complicated". |
50 |
> |
51 |
> Not really. It's been getting more complicated since long before I |
52 |
> starting working in it in 1980. Nothing's changed there. |
53 |
> |
54 |
>> We have Linux running in the same beige machines it has been running |
55 |
>> since 1991, but it also runs in TVs, tablets, cellphones, fridges, |
56 |
>> cars, ebook readers, and (soon enough, I'm sure) the kitchen sink. |
57 |
>> This devices behave very differently from our old and beloved beige |
58 |
>> boxen. |
59 |
> |
60 |
> Not at the level of needing device nodes under /dev and drivers connected |
61 |
> to them, they haven't. |
62 |
> |
63 |
>> They need to handle lots of different hardware comming and going, via |
64 |
>> USB, Firewire, Bluetooth, WIMAX, and who knows what else in the future. |
65 |
> |
66 |
> Yes. That's why there's a generic facility for building arbitrary |
67 |
> drivers into a kernel. That's not new either. |
68 |
> |
69 |
>> The principal idea behind udev, is that we *don't* kown (we *can't* |
70 |
>> know) what hardware this or that machine is gonna have at some point. |
71 |
>> And we want the machine (and the new hardware) to "just work" when |
72 |
>> they are connected. |
73 |
> |
74 |
> Huh? What's that to do with udev? You're talking at far too high a |
75 |
> level of abstraction. The new hardware will "just work" if there are the |
76 |
> correct drivers built in. That's as true of udev as it is of mdev as it |
77 |
> is of the old static /dev with mknod. |
78 |
|
79 |
No, it is not. You are letting out the sine qua non of the matter: the |
80 |
device has to be built, *and the /dev file should exists*. I hope you |
81 |
are not suggesting that we put *ALL* the possible files under /dev, |
82 |
because that was the idea before devfs, and it doesn't work *IN |
83 |
GENERAL*. |
84 |
|
85 |
So, you need something to handle device files on /dev, so you don't |
86 |
need every possible device file for every possible piece of hardware. |
87 |
But then you want to handle the same device with the same device name, |
88 |
so you need some kind of database. Then for the majority of users, |
89 |
they want to see *something* happen when they connect aa piece of |
90 |
hardware to their computers. So you need to handle the events |
91 |
associated with the connections (or discovery, for things like |
92 |
Bluetooth) of the devices, and since udev is already handling the |
93 |
database and the detection of connections/discovery, I agree with the |
94 |
decision of leting udev to execute programs when something gets |
95 |
connected. You could get that function in another program, but you are |
96 |
only moving the problem, *and it can also happen very early at boot |
97 |
time*, so lets udev handle it all the time. |
98 |
|
99 |
I hope you see where I'm going. As I said before, mdev could (in |
100 |
theory) do the same that udev does. But then it will be as complicated |
101 |
as udev, *because it is a complicated problem* in general. And I again |
102 |
use my fuel injection analogy: it is not *necessary*. It is just very |
103 |
damn convenient. |
104 |
|
105 |
> [ .... ] |
106 |
> |
107 |
>> So, yeah, it's more complicated. The world got complicate; better get |
108 |
>> used to it. |
109 |
> |
110 |
> You're bluffing, aren't you? You really don't have any more idea than I |
111 |
> do about the technical motivation for udev, do you? |
112 |
|
113 |
I'm not, and I have a really time understanding why you don't see the |
114 |
complexity on the problem. I explained above: it is a complicated |
115 |
problem (when dealing with the general case), and therefore the |
116 |
(general) solution is bound to be also complicated. |
117 |
|
118 |
You want it simple? Tha'ts fine, it is possible. It's just that it |
119 |
will not solve the general problem, just a very specific subset of it. |
120 |
Just as mdev is doing; Walt just posted an email explaining that if |
121 |
you use GNOME, KDE, XFCE, or LVM2, mdev is not for you. |
122 |
|
123 |
I will not be surprised if in the future the list of programs "not for |
124 |
mdev" only grows. |
125 |
|
126 |
Regards. |
127 |
-- |
128 |
Canek Peláez Valdés |
129 |
Posgrado en Ciencia e Ingeniería de la Computación |
130 |
Universidad Nacional Autónoma de México |