1 |
On Wed, Mar 14, 2012 at 9:16 AM, Alan Mackenzie <acm@×××.de> wrote: |
2 |
> Hello, Canek |
3 |
> |
4 |
> On Tue, Mar 13, 2012 at 06:07:32PM -0600, Canek Peláez Valdés wrote: |
5 |
>> On Tue, Mar 13, 2012 at 5:03 PM, Alan Mackenzie <acm@×××.de> wrote: |
6 |
> |
7 |
>> > The new hardware will "just work" if there are the correct drivers |
8 |
>> >built in. That's as true of udev as it is of mdev as it is of the old |
9 |
>> >static /dev with mknod. |
10 |
> |
11 |
>> No, it is not. You are letting out the sine qua non of the matter: the |
12 |
>> device has to be built, *and the /dev file should exists*. I hope you |
13 |
>> are not suggesting that we put *ALL* the possible files under /dev, |
14 |
>> because that was the idea before devfs, and it doesn't work *IN |
15 |
>> GENERAL*. |
16 |
> |
17 |
> Previously you made appropriate /dev entries with mknod, giving the |
18 |
> device major and minor numbers as parameters. This appeared to work in |
19 |
> general - I'm not aware of any device it didn't work for. |
20 |
|
21 |
Again, I believe you are not following me. In *general* the number of |
22 |
potential device files under /dev is not bounded. Given N device |
23 |
filess, I can give you an example where you would need N+1 device |
24 |
files. With your experience, I assume you know about huge arrays of |
25 |
SCSI disks, for example; add to that whatever number of USB devices |
26 |
(and the hubs necessary to connect them), whatever number of Bluetooth |
27 |
thingies, etc., etc. |
28 |
|
29 |
Therefore, mknod doesn't solve the problem in general, because I can |
30 |
always give an example where the preset device files on /dev are not |
31 |
enough. |
32 |
|
33 |
>> So, you need something to handle device files on /dev, so you don't |
34 |
>> need every possible device file for every possible piece of hardware. |
35 |
>> But then you want to handle the same device with the same device name, |
36 |
>> so you need some kind of database. Then for the majority of users, |
37 |
>> they want to see *something* happen when they connect aa piece of |
38 |
>> hardware to their computers. |
39 |
> |
40 |
> That happened under the old static /dev system. What was that /dev |
41 |
> system, if not a database matching /dev names to device numbers? I'm not |
42 |
> sure what you mean by "same device" and "same device name". |
43 |
|
44 |
That if I connect a USB wi-fi dongle, and it appears with the name |
45 |
wlan23, I want *every* time that dongle to have the wlan23 name .Good |
46 |
luck doing that without a database. |
47 |
|
48 |
>> So you need to handle the events associated with the connections (or |
49 |
>> discovery, for things like Bluetooth) of the devices, and since udev is |
50 |
>> already handling the database and the detection of |
51 |
>> connections/discovery, I agree with the decision of leting udev to |
52 |
>> execute programs when something gets connected. You could get that |
53 |
>> function in another program, but you are only moving the problem, *and |
54 |
>> it can also happen very early at boot time*, so lets udev handle it all |
55 |
>> the time. |
56 |
> |
57 |
> Early in boot time, you only need things like disk drives, graphic cards |
58 |
> and keyboards. Anything else can be postponed till late boot time. |
59 |
|
60 |
Bluetooth keyboards. Done, you made my system unbootable when I need |
61 |
to run fsck by hand after a power failure. |
62 |
|
63 |
>> I hope you see where I'm going. As I said before, mdev could (in |
64 |
>> theory) do the same that udev does. But then it will be as complicated |
65 |
>> as udev, *because it is a complicated problem* in general. And I again |
66 |
>> use my fuel injection analogy: it is not *necessary*. It is just very |
67 |
>> damn convenient. |
68 |
> |
69 |
> It may be a complicated problem in general, but many people do not need |
70 |
> that generality. |
71 |
|
72 |
^^^^^ That's your mistake! (IMHO). I explain below. |
73 |
|
74 |
> I suspect the vast majority don't need it. Neither the |
75 |
> typical desktop, the typical server, nor typical embedded devices like |
76 |
> routers. |
77 |
|
78 |
Alan, the "vast majority" of Linux users right now are phone users. |
79 |
That was my initial point some mails ago. What *you* believe are |
80 |
"regular" users (people like you, or maybe even me), stopped being |
81 |
true a couple of years ago. The days of the Unix admin and workstation |
82 |
user are going the way of the dodo. |
83 |
|
84 |
At least, that's how I see it. |
85 |
|
86 |
>> I have a really time understanding why you don't see the complexity on |
87 |
>> the problem. I explained above: it is a complicated problem (when |
88 |
>> dealing with the general case), and therefore the (general) solution is |
89 |
>> bound to be also complicated. |
90 |
> |
91 |
> I've had a hard time understanding, because up till now, nobody's |
92 |
> described the problem in detail - there's only been hand-waving. |
93 |
> |
94 |
>> You want it simple? Tha'ts fine, it is possible. It's just that it |
95 |
>> will not solve the general problem, just a very specific subset of it. |
96 |
> |
97 |
> That subset used by the vast majority of Linux users. |
98 |
|
99 |
Again, think about phones. And tablets. And TVs. And |
100 |
[insert-here-cool-gadgets-from-the-future]. |
101 |
|
102 |
> And yes, I do want |
103 |
> it simple, because elegant simplicity is the best way, IMAO. You, on the |
104 |
> other hand, seem to love complicated solutions because they are "the way |
105 |
> forward". We'll have to agree to disagree on this one. |
106 |
|
107 |
No, it's not a matter of "that's the way forward". It's a matter of |
108 |
trying to solve the general problem. And since the general solution |
109 |
also solves the simple cases, I don't see a reason to waste my |
110 |
time/resources in a solution that in the end will not solve the |
111 |
general problem. |
112 |
|
113 |
Of course, as I have been saying from the beginning, this is |
114 |
OpenSource. Want to pour some effort into solving the simple cases |
115 |
that will not help all the community, and that it will only help in |
116 |
fact a minority, that's your prerogative (and Walt's, and Vapier's, |
117 |
and everyone else that don't like the "complex" but complete |
118 |
solution). Go nuts with it if you want. |
119 |
|
120 |
But please don't dismiss the general solution as "unnecessary" complex |
121 |
when it's not the case, and don't think that the "simple" setups |
122 |
(whatever that means) are the majority. Again, think phones and |
123 |
tablets: those *are* the majority. |
124 |
|
125 |
>> Just as mdev is doing; Walt just posted an email explaining that if |
126 |
>> you use GNOME, KDE, XFCE, or LVM2, mdev is not for you. |
127 |
> |
128 |
> Walter is, I believe, mistaken here. I can mount and use my LVM2 |
129 |
> partitions. Gnome looks like it comes up OK, but that could be moot, |
130 |
> since right now I haven't got keyboard/mouse drivers under the X server. |
131 |
|
132 |
Oh, for sure you can modify LVM2 to work under mdev. Also |
133 |
GNOME/KDE/XFCE, and everything under the sun. You have the source; you |
134 |
can do *anything* you want with it. |
135 |
|
136 |
But the effort wasted^^^^^Hpoured in that excercise will only serve a |
137 |
handful of users, and it will be never accepted upstream, because |
138 |
upstream is (rightfully) concerned with the general problem. |
139 |
|
140 |
Again, this is OpenSource: go nuts with any problem you find |
141 |
"interesting" (I really don't understand why solving a particular case |
142 |
of the general problem will be more interesting that solving the |
143 |
former, but that is maybe the Computer Scientist in me). |
144 |
|
145 |
I'm more interested in the general solution that will work not only |
146 |
for my current machines, but also for the ones I'm planning to have in |
147 |
the future. I'm dying to get a tablet where I can put GNOME 3 on it; I |
148 |
can bet you another beer that mdev will be not enough to handle that. |
149 |
|
150 |
>> I will not be surprised if in the future the list of programs "not for |
151 |
>> mdev" only grows. |
152 |
> |
153 |
> There's a difference between "needed by portage" and "doesn't work under |
154 |
> mdev". As I say, it will all be moot if the evdev driver won't work |
155 |
> under mdev. |
156 |
|
157 |
With all due respect, Alan (and this is completely sincere, in this |
158 |
list you are of the guys I respect the most), I believe you are |
159 |
thinking too small. |
160 |
|
161 |
Right now Linux runs in my phone, my TV's, my routers and every |
162 |
computer I own. I have a couple of Windows installations, which I use |
163 |
once or twice every three months (I ported a PyGTK program to Windows |
164 |
last week, so I had to boot into Windows for the first time this |
165 |
year). I want Linux running on *everything*, and what is more: I don't |
166 |
want android in my handhelds, I want the full GNOME experience. |
167 |
|
168 |
To accomplish that we need udev; mdev it's just not enough. |
169 |
|
170 |
Regards. |
171 |
-- |
172 |
Canek Peláez Valdés |
173 |
Posgrado en Ciencia e Ingeniería de la Computación |
174 |
Universidad Nacional Autónoma de México |