1 |
On Wed, Mar 14, 2012 at 12:09 PM, Michael Mol <mikemol@×××××.com> wrote: |
2 |
> On Wed, Mar 14, 2012 at 1:22 PM, Canek Peláez Valdés <caneko@×××××.com> wrote: |
3 |
>> On Wed, Mar 14, 2012 at 9:16 AM, Alan Mackenzie <acm@×××.de> wrote: |
4 |
>>> Hello, Canek |
5 |
>>> |
6 |
>>> On Tue, Mar 13, 2012 at 06:07:32PM -0600, Canek Peláez Valdés wrote: |
7 |
>>>> On Tue, Mar 13, 2012 at 5:03 PM, Alan Mackenzie <acm@×××.de> wrote: |
8 |
>>> |
9 |
>>>> > The new hardware will "just work" if there are the correct drivers |
10 |
>>>> >built in. That's as true of udev as it is of mdev as it is of the old |
11 |
>>>> >static /dev with mknod. |
12 |
>>> |
13 |
>>>> No, it is not. You are letting out the sine qua non of the matter: the |
14 |
>>>> device has to be built, *and the /dev file should exists*. I hope you |
15 |
>>>> are not suggesting that we put *ALL* the possible files under /dev, |
16 |
>>>> because that was the idea before devfs, and it doesn't work *IN |
17 |
>>>> GENERAL*. |
18 |
>>> |
19 |
>>> Previously you made appropriate /dev entries with mknod, giving the |
20 |
>>> device major and minor numbers as parameters. This appeared to work in |
21 |
>>> general - I'm not aware of any device it didn't work for. |
22 |
>> |
23 |
>> Again, I believe you are not following me. In *general* the number of |
24 |
>> potential device files under /dev is not bounded. Given N device |
25 |
>> filess, I can give you an example where you would need N+1 device |
26 |
>> files. With your experience, I assume you know about huge arrays of |
27 |
>> SCSI disks, for example; add to that whatever number of USB devices |
28 |
>> (and the hubs necessary to connect them), whatever number of Bluetooth |
29 |
>> thingies, etc., etc. |
30 |
>> |
31 |
>> Therefore, mknod doesn't solve the problem in general, because I can |
32 |
>> always give an example where the preset device files on /dev are not |
33 |
>> enough. |
34 |
> |
35 |
> And I can always give an example where there can't be enough inodes |
36 |
> (or perhaps even RAM) to contain enough device nodes. "General Case" |
37 |
> is a beautiful thing for a theoretical system, but my computer is not |
38 |
> a theoretical system. Neither is my phone, or my server. |
39 |
|
40 |
You are arguing that the mknod method should be used? Because that |
41 |
dicussion happened ten years ago; that train is long gone. If you want |
42 |
to argue with someone about it, it would not be me. |
43 |
|
44 |
> |
45 |
>> |
46 |
>>>> So, you need something to handle device files on /dev, so you don't |
47 |
>>>> need every possible device file for every possible piece of hardware. |
48 |
>>>> But then you want to handle the same device with the same device name, |
49 |
>>>> so you need some kind of database. Then for the majority of users, |
50 |
>>>> they want to see *something* happen when they connect aa piece of |
51 |
>>>> hardware to their computers. |
52 |
>>> |
53 |
>>> That happened under the old static /dev system. What was that /dev |
54 |
>>> system, if not a database matching /dev names to device numbers? I'm not |
55 |
>>> sure what you mean by "same device" and "same device name". |
56 |
>> |
57 |
>> That if I connect a USB wi-fi dongle, and it appears with the name |
58 |
>> wlan23, I want *every* time that dongle to have the wlan23 name .Good |
59 |
>> luck doing that without a database. |
60 |
> |
61 |
> udev does something nice here, and I believe mdev is capable of |
62 |
> similar. sysfs exports device attributes such as model and serial |
63 |
> number, and you could trivially derive the node name from that. |
64 |
|
65 |
I think (as does the udev maintainers) that there should be a strong |
66 |
coupling between the device manager, the database handling, and the |
67 |
firing of scripts. Otherwise. we get back to devfs, which again, that |
68 |
train is long gone. |
69 |
|
70 |
>> |
71 |
>>>> So you need to handle the events associated with the connections (or |
72 |
>>>> discovery, for things like Bluetooth) of the devices, and since udev is |
73 |
>>>> already handling the database and the detection of |
74 |
>>>> connections/discovery, I agree with the decision of leting udev to |
75 |
>>>> execute programs when something gets connected. You could get that |
76 |
>>>> function in another program, but you are only moving the problem, *and |
77 |
>>>> it can also happen very early at boot time*, so lets udev handle it all |
78 |
>>>> the time. |
79 |
>>> |
80 |
>>> Early in boot time, you only need things like disk drives, graphic cards |
81 |
>>> and keyboards. Anything else can be postponed till late boot time. |
82 |
>> |
83 |
>> Bluetooth keyboards. Done, you made my system unbootable when I need |
84 |
>> to run fsck by hand after a power failure. |
85 |
> |
86 |
> The userland bluetooth stack is an abomination. (Actually, the _whole_ |
87 |
> bluetooth stack is an abomination. You don't want to know what |
88 |
> embedded developers who build car stereos and the like have to go |
89 |
> through to try to test things. Or what real packets fundamentally look |
90 |
> like 'on the wire'.) |
91 |
> |
92 |
> It needs a real overhaul. I used to use a bluetooth keyboard, but I |
93 |
> found it to be a real mess. I even joined the Linux Documentation |
94 |
> Project with the intent of getting bluetooth profiles, apps and stacks |
95 |
> indexed and cross-referenced, but there's just way too much going |
96 |
> wrong with bluetooth. I eventually switched to using a propriety |
97 |
> wireless keyboard, and relegated the bluetooth keyboard to secondary |
98 |
> access and to controlling the PS3. |
99 |
> |
100 |
> Besides, your BIOS isn't going to support bluetooth, either; if you're |
101 |
> concerned about failure-case recovery, and you don't have a keyboard |
102 |
> you can navigate your BIOS with, you're very probably doing something |
103 |
> wrong. |
104 |
|
105 |
BIOS is going the way of the dodo too, but that's besides the point. |
106 |
I'm actually quite happy with the Linux bluetooth stack (which, if I'm |
107 |
not mistaken, is used by Android). I have several bluetooth thingies, |
108 |
they all work great. |
109 |
|
110 |
|
111 |
>> |
112 |
>>>> I hope you see where I'm going. As I said before, mdev could (in |
113 |
>>>> theory) do the same that udev does. But then it will be as complicated |
114 |
>>>> as udev, *because it is a complicated problem* in general. And I again |
115 |
>>>> use my fuel injection analogy: it is not *necessary*. It is just very |
116 |
>>>> damn convenient. |
117 |
>>> |
118 |
>>> It may be a complicated problem in general, but many people do not need |
119 |
>>> that generality. |
120 |
>> |
121 |
>> ^^^^^ That's your mistake! (IMHO). I explain below. |
122 |
>> |
123 |
>>> I suspect the vast majority don't need it. Neither the |
124 |
>>> typical desktop, the typical server, nor typical embedded devices like |
125 |
>>> routers. |
126 |
>> |
127 |
>> Alan, the "vast majority" of Linux users right now are phone users. |
128 |
> |
129 |
> Phone users are _excellent_ examples of embedded environments. You |
130 |
> have a static hardware set, where you can predict darn near everything |
131 |
> about it that you might possibly need during a boot sequence. You're |
132 |
> not expected or intended to cope with boot failures. Your bluetooth |
133 |
> earpiece and input devices can wait until the OS has loaded. |
134 |
> |
135 |
> This is exactly the kind of environment where I would expect udev to |
136 |
> _not_ be necessary during boot. |
137 |
|
138 |
The phones/tablets of now have everything but a "static hardware set". |
139 |
The connect (wirelessly usually) with a lot of things, and they have |
140 |
USB and SD besides. So I would expect udev to *be* necessary with |
141 |
them. |
142 |
|
143 |
I'm still wainting for someone to tell me how mdev handles bluetooth. |
144 |
|
145 |
>> That was my initial point some mails ago. What *you* believe are |
146 |
>> "regular" users (people like you, or maybe even me), stopped being |
147 |
>> true a couple of years ago. The days of the Unix admin and workstation |
148 |
>> user are going the way of the dodo. |
149 |
>> |
150 |
>> At least, that's how I see it. |
151 |
> |
152 |
> I can only assume you've run a server. I expect you currently run at |
153 |
> least one. If you haven't, then you _really_ have no standing to argue |
154 |
> that server environments are irrelevant; you'd be belying a massive |
155 |
> lack of understanding of systemic, practical and operational context. |
156 |
> I can't _imagine_ you expect the client/server architecture of the |
157 |
> Internet to go away in the near future. You're very explicitly talking |
158 |
> about sacrificing Linux's efficiency in a server environment in favor |
159 |
> of The General Case, which is a case which should only be needed once |
160 |
> the system has already booted. |
161 |
|
162 |
"sacrificing Linux's efficiency in a server environment"? What are you |
163 |
talking about? I run my servers with udev... *and* systemd. Have you |
164 |
tried it? Are you *sure* it's less efficient, or it seems so to you |
165 |
"in theory"? |
166 |
|
167 |
More complex doesn't mean less efficient: again, look at the fuel |
168 |
injection analogy. It's incredible complex, but it gives you *more* |
169 |
fuel efficiency. |
170 |
|
171 |
The general solution is *specially* important for the server case. |
172 |
Kay and Lennart work for RedHat, and be sure RHEL will have udev and |
173 |
systemd at some point. And guess what? I'm willing to bet another beer |
174 |
that it would be more efficient. |
175 |
|
176 |
> We used to joke that emacs would be a great operating system if only |
177 |
> it had drivers. From your arguments and positions, it's looking like |
178 |
> udev is setting itself to be the next target of similar jokes. |
179 |
|
180 |
Maybe it's coincidence, but I still use Emacs ;) |
181 |
|
182 |
Read the last mail from Greg KH in the -dev list: more coupling is |
183 |
what most of the devs are looking for, because *it solves more cases* |
184 |
of the general problem. |
185 |
|
186 |
> |
187 |
>> |
188 |
>>>> I have a really time understanding why you don't see the complexity on |
189 |
>>>> the problem. I explained above: it is a complicated problem (when |
190 |
>>>> dealing with the general case), and therefore the (general) solution is |
191 |
>>>> bound to be also complicated. |
192 |
>>> |
193 |
>>> I've had a hard time understanding, because up till now, nobody's |
194 |
>>> described the problem in detail - there's only been hand-waving. |
195 |
>>> |
196 |
>>>> You want it simple? Tha'ts fine, it is possible. It's just that it |
197 |
>>>> will not solve the general problem, just a very specific subset of it. |
198 |
>>> |
199 |
>>> That subset used by the vast majority of Linux users. |
200 |
>> |
201 |
>> Again, think about phones. And tablets. And TVs. And |
202 |
>> [insert-here-cool-gadgets-from-the-future]. |
203 |
> |
204 |
> See my argument above about static, predictable hardware, |
205 |
> strictly-defined boot process and clear stages of operation. |
206 |
|
207 |
Again, if it's simpler/easier, why has anybody implemented it? And |
208 |
please, don't say "mdev", because (as I have said), it doesn't work |
209 |
*right now* for all my use cases. When it does, I keep betting that it |
210 |
would be as complex as udev. |
211 |
|
212 |
>> |
213 |
>>> And yes, I do want |
214 |
>>> it simple, because elegant simplicity is the best way, IMAO. You, on the |
215 |
>>> other hand, seem to love complicated solutions because they are "the way |
216 |
>>> forward". We'll have to agree to disagree on this one. |
217 |
>> |
218 |
>> No, it's not a matter of "that's the way forward". It's a matter of |
219 |
>> trying to solve the general problem. And since the general solution |
220 |
>> also solves the simple cases, I don't see a reason to waste my |
221 |
>> time/resources in a solution that in the end will not solve the |
222 |
>> general problem. |
223 |
> |
224 |
> Honestly, you're too dead set on finding a solution to the general |
225 |
> problem, because to solve the general problem, you must redefine |
226 |
> reality to cope with the limits of your theory. In order to handle the |
227 |
> burden of your general-case-software, hardware itself must become more |
228 |
> powerful and more expensive, which in turn will lead to greater |
229 |
> complexity for your general case. Old hardware, no longer capable of |
230 |
> running the general case software, even though it's a specific-case |
231 |
> device, is wastefully discarded. |
232 |
|
233 |
What are you talking about man? The "general problem", by definition, |
234 |
includes old hardware. That's why it's "general". |
235 |
|
236 |
I think you guys are not seeing the forest because of all the trees. |
237 |
|
238 |
> |
239 |
>> |
240 |
>> Of course, as I have been saying from the beginning, this is |
241 |
>> OpenSource. Want to pour some effort into solving the simple cases |
242 |
>> that will not help all the community, and that it will only help in |
243 |
>> fact a minority, that's your prerogative (and Walt's, and Vapier's, |
244 |
>> and everyone else that don't like the "complex" but complete |
245 |
>> solution). Go nuts with it if you want. |
246 |
>> |
247 |
>> But please don't dismiss the general solution as "unnecessary" complex |
248 |
>> when it's not the case, and don't think that the "simple" setups |
249 |
>> (whatever that means) are the majority. Again, think phones and |
250 |
>> tablets: those *are* the majority. |
251 |
> |
252 |
> Again, phones and tablets are simple cases. |
253 |
|
254 |
OK; call me when they use mdev. |
255 |
|
256 |
>> |
257 |
>>>> Just as mdev is doing; Walt just posted an email explaining that if |
258 |
>>>> you use GNOME, KDE, XFCE, or LVM2, mdev is not for you. |
259 |
>>> |
260 |
>>> Walter is, I believe, mistaken here. I can mount and use my LVM2 |
261 |
>>> partitions. Gnome looks like it comes up OK, but that could be moot, |
262 |
>>> since right now I haven't got keyboard/mouse drivers under the X server. |
263 |
>> |
264 |
>> Oh, for sure you can modify LVM2 to work under mdev. Also |
265 |
>> GNOME/KDE/XFCE, and everything under the sun. You have the source; you |
266 |
>> can do *anything* you want with it. |
267 |
>> |
268 |
>> But the effort wasted^^^^^Hpoured in that excercise will only serve a |
269 |
>> handful of users, and it will be never accepted upstream, because |
270 |
>> upstream is (rightfully) concerned with the general problem. |
271 |
> |
272 |
> And here is the biggest reason I get frustrated with you. You say "go |
273 |
> ahead and try, you're wasting your effort. You're going to fail. |
274 |
> Everyone will leave you behind." It's an incredibly negative, |
275 |
> aggressive attitude which isn't geared toward finding a solution, but |
276 |
> is rather geared at reducing the problem. |
277 |
|
278 |
I'm just stating my opinion; if you find it "negative", well sorry. |
279 |
Disagree with me if you want, but (obviously) I don't think or see the |
280 |
problem as you guys. I'm not being "negative"; I'm just call'em as I |
281 |
see'em. |
282 |
|
283 |
And besides, it matters not what I say or don't say, because what |
284 |
matters is the *code*. And the code of udev works right now in the |
285 |
general case; mdev (as cute hack as it could be) doesn't. That's all |
286 |
what I'm saying. |
287 |
|
288 |
|
289 |
>> |
290 |
>> Again, this is OpenSource: go nuts with any problem you find |
291 |
>> "interesting" (I really don't understand why solving a particular case |
292 |
>> of the general problem will be more interesting that solving the |
293 |
>> former, but that is maybe the Computer Scientist in me). |
294 |
> |
295 |
> That's exactly what it is. I have a _lot_ of interest in (and respect |
296 |
> for) computer science[1], but I also have several years of practical, |
297 |
> real-world software development. I have the privilege of being allowed |
298 |
> to see and participate in both the realms of theory and of practice. |
299 |
> |
300 |
> I'm not the smartest or most knowledgeable guy on this mailing list, |
301 |
> but I think I might know enough to say that, yes, you have too strong |
302 |
> a focus on the general case. |
303 |
|
304 |
Wellm, yes. That's what I have been saying. |
305 |
|
306 |
> |
307 |
>> |
308 |
>> I'm more interested in the general solution that will work not only |
309 |
>> for my current machines, but also for the ones I'm planning to have in |
310 |
>> the future. I'm dying to get a tablet where I can put GNOME 3 on it; I |
311 |
>> can bet you another beer that mdev will be not enough to handle that. |
312 |
> |
313 |
> The fundamental problem, as I see it, is that udev's role currently |
314 |
> encompasses both runtime hotplug events and boot-time |
315 |
> responsibilities. Those need to be separated. How? I don't have a |
316 |
> quick or easy answer, but that's where I see the systemic problem. |
317 |
> (And, no, I won't suggest that HAL is the solution.) |
318 |
|
319 |
Again, read about devfs. Tighly coupling is the path the developers |
320 |
(in general) are taking. I agree with them. |
321 |
|
322 |
|
323 |
> |
324 |
>> |
325 |
>>>> I will not be surprised if in the future the list of programs "not for |
326 |
>>>> mdev" only grows. |
327 |
>>> |
328 |
>>> There's a difference between "needed by portage" and "doesn't work under |
329 |
>>> mdev". As I say, it will all be moot if the evdev driver won't work |
330 |
>>> under mdev. |
331 |
>> |
332 |
>> With all due respect, Alan (and this is completely sincere, in this |
333 |
>> list you are of the guys I respect the most), I believe you are |
334 |
>> thinking too small. |
335 |
> |
336 |
> And I think you're thinking too big. |
337 |
|
338 |
Thank you. |
339 |
|
340 |
> Every case you would reach for to |
341 |
> cover with your general case, there will be a case just outside your |
342 |
> reach. At some point, you need to express limits. Limits are fine. |
343 |
> Limits can be practical. Heck, reasonable limits make practice easier, |
344 |
> because known constraints help one predict the behavior of the system. |
345 |
|
346 |
I know limits. udev has a lot of limitations; but it can do anything |
347 |
mdev can, and more. I'm not talking from a pure theoretical POV. |
348 |
|
349 |
>> |
350 |
>> Right now Linux runs in my phone, my TV's, my routers and every |
351 |
>> computer I own. I have a couple of Windows installations, which I use |
352 |
>> once or twice every three months (I ported a PyGTK program to Windows |
353 |
>> last week, so I had to boot into Windows for the first time this |
354 |
>> year). I want Linux running on *everything*, and what is more: I don't |
355 |
>> want android in my handhelds, I want the full GNOME experience. |
356 |
> |
357 |
> BTW, you've put yourself into a niche here; you want a general-purpose |
358 |
> platform in embedded devices, but that's not the environment you've |
359 |
> argued the majory of Linux users exist in. I agree the majority of |
360 |
> Linux users are probably running Android at this point. They're not |
361 |
> running a general-purpose platform. |
362 |
|
363 |
And the devs are planning on changing that ;) That's the whole point |
364 |
of all this udev mess. |
365 |
|
366 |
|
367 |
>> |
368 |
>> To accomplish that we need udev; mdev it's just not enough. |
369 |
>> |
370 |
>> Regards. |
371 |
>> -- |
372 |
>> Canek Peláez Valdés |
373 |
>> Posgrado en Ciencia e Ingeniería de la Computación |
374 |
>> Universidad Nacional Autónoma de México |
375 |
>> |
376 |
> |
377 |
> [1] Don't believe me? I started and continue to operate and fund |
378 |
> Rosetta Code with the specific and ongoing interest in providing a |
379 |
> tool which helps to improve the state of the art. (Watching and |
380 |
> learning from a mix of practical and academic expert users of hundreds |
381 |
> of different programming languages has been a great experience, too.) |
382 |
|
383 |
I believe you. I'm finishing my PhD in Computer Science, but I have |
384 |
years of experience administering servers and coding as professional |
385 |
programmer. And I strongly disagree with how you guys see things. |
386 |
|
387 |
Regards. |
388 |
-- |
389 |
Canek Peláez Valdés |
390 |
Posgrado en Ciencia e Ingeniería de la Computación |
391 |
Universidad Nacional Autónoma de México |