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