1 |
On Wed, Mar 14, 2012 at 1:24 PM, Pandu Poluan <pandu@××××××.info> wrote: |
2 |
> |
3 |
> On Mar 15, 2012 1:22 AM, "Canek Peláez Valdés" <caneko@×××××.com> wrote: |
4 |
>> |
5 |
>> On Wed, Mar 14, 2012 at 12:03 PM, Pandu Poluan <pandu@××××××.info> wrote: |
6 |
>> > |
7 |
>> > On Mar 15, 2012 12:25 AM, "Canek Peláez Valdés" <caneko@×××××.com> |
8 |
>> > wrote: |
9 |
>> >> |
10 |
>> > |
11 |
>> > ---- >8 snip |
12 |
>> > |
13 |
>> >> |
14 |
>> >> That if I connect a USB wi-fi dongle, and it appears with the name |
15 |
>> >> wlan23, I want *every* time that dongle to have the wlan23 name .Good |
16 |
>> >> luck doing that without a database. |
17 |
>> >> |
18 |
>> > |
19 |
>> > That could -- should -- be handled by a script or a program that looks |
20 |
>> > up |
21 |
>> > the database, do the checks, and rename the node accordingly. |
22 |
>> > |
23 |
>> > All the device manager got to do is to plug in into the hotplug kernel |
24 |
>> > knob, |
25 |
>> > whereby it will be invoked on every hotplug event, and depending on the |
26 |
>> > nature if the device (which, in your example, fits the pattern "wlan*") |
27 |
>> > fires the script/program which performs the lookup+rename part. |
28 |
>> > |
29 |
>> > mdev can do that. |
30 |
>> |
31 |
>> udev already does it. |
32 |
>> |
33 |
> |
34 |
> So does mdev. If writing a simple script is so distressing for you, why in |
35 |
> the world are you using Gentoo, with all its manual labor? |
36 |
|
37 |
Whoa, relax man. We are discussing (or at least I'm trying) in a civil |
38 |
manner the technical merits of two proposed solutions for a problem. |
39 |
No need to get personal. |
40 |
|
41 |
(And BTW, I've been using Gentoo since 2003, and I maintain an overlay |
42 |
to use systemd without the need of having openrc/baselayout |
43 |
installed). |
44 |
|
45 |
>> > Put it under /bin |
46 |
>> > |
47 |
>> > Done. |
48 |
>> |
49 |
>> Yeah, right. And put LVM2 binaries in /bin. And wpa_supplicant (maybe |
50 |
>> I need a wireless connected NFS share). And... |
51 |
>> |
52 |
>> Not scalable. Doesn't solve the general case. You are seeing too small. |
53 |
>> |
54 |
> |
55 |
> *You* are not seeing _at all_. Witness how the Fedora devs want to merge |
56 |
> /bin and /sbin |
57 |
|
58 |
Yeah. I agree with their decision. Read: |
59 |
|
60 |
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html |
61 |
|
62 |
> It *is* scalable. Ever tried du /usr? |
63 |
|
64 |
Yeah, from time to time. Fail to see your point. |
65 |
|
66 |
> The problem was -- is -- that package maintainers blindly put binaries |
67 |
> required for booting into /usr |
68 |
|
69 |
No problem with an intiramfs :D |
70 |
|
71 |
>> > The vast majority of Linux users, be they using PCs or smartphones, only |
72 |
>> > need a mechanism to handle hotplugs. |
73 |
>> > |
74 |
>> > udev can do it, but so can mdev (with the help of helper |
75 |
>> > scripts/programs). |
76 |
>> |
77 |
>> udev can do it *right now*, no hacks involved. Go and hack mdev until |
78 |
>> it handles *ALL* the cases udev handles, and see how complex it gets. |
79 |
>> |
80 |
> |
81 |
> If you're so afraid of doing things manually, you have no business using |
82 |
> Gentoo in the first place. |
83 |
|
84 |
Again with the personal attacks; relax man. No need to get all worked out. |
85 |
|
86 |
> Here's a prototype script to ensure that certain NICs will always end up the |
87 |
> way you want it named: |
88 |
> |
89 |
> #!/bin/sh |
90 |
> mac="$( cat /proc/net/arp | awk -V dev="$MDEV" 'NR==1{next} $6==dev {print |
91 |
> $4}')" |
92 |
> name="$(awk -V mac="$mac" '$1==mac {print $2}')" |
93 |
> [ "$name" ] && mv /dev/$MDEV /dev/$name |
94 |
> exit 0 |
95 |
> |
96 |
> (Prototype, because I don't have access to a Linux box atm, so I can't test) |
97 |
|
98 |
Yeah, I'm gonna try that instead of udev, which works out of the box. |
99 |
I'm gonna pass, thank you. |
100 |
|
101 |
>> Been there, tried that. What do you think devfs was? We tried this |
102 |
>> path already: it doesn't work, it doesn't scale. You couple together |
103 |
>> the device manager and the database handling and the firing of |
104 |
>> associated scripts because that's the technical correct solution. It |
105 |
>> *is* more complex, for sure, but so it's the general problem we are |
106 |
>> trying to solve. |
107 |
>> |
108 |
> |
109 |
> If you step down from your high chair for awhile and read the busybox thread |
110 |
> I've been linking, you'll know the difference. One of the emails in that |
111 |
> thread explained it. |
112 |
|
113 |
Relax, I'm not on a high chair; again, I'm just stating my opinion. I |
114 |
have read the mail, I think the day it was posted. I don't buy it, for |
115 |
all the reasons I have been saying. |
116 |
|
117 |
>> > udev is going the kitchen sink route. mdev stays the lego brick path. |
118 |
>> |
119 |
>> And guess what? I don't want a toy solution built with lego blocks. |
120 |
> |
121 |
> Obviously idioms went way over your head. |
122 |
> |
123 |
> If you're taking the "Lego brick" allegory as literal, then good luck with |
124 |
> your kitchen sink. At least I know that with Lego bricks, amazing works of |
125 |
> art have been created. :-P |
126 |
|
127 |
:D |
128 |
|
129 |
Actually, a Lego brick is a good analogy for mdev (in its current |
130 |
state). It's a beautiful toy; but again, nobody has pointed out how to |
131 |
make it work with bluetooth devices, for example. From Walt's mail |
132 |
(his words, not mine): |
133 |
|
134 |
"This revision includes some checking to see if your system can run |
135 |
without udev. In general, if you use any of... |
136 |
* GNOME |
137 |
* KDE |
138 |
* XFCE |
139 |
* lvm2 |
140 |
... you probably need udev, so mdev is not for you." |
141 |
|
142 |
>> I |
143 |
>> want a robust, general solution, that it is bound to work *now* and in |
144 |
>> the future. |
145 |
>> |
146 |
> |
147 |
> So? What makes you think that in the future suddenly mdev stops working? |
148 |
|
149 |
I doesn't work, out of the box, right now. Again, see Walt's mail. |
150 |
|
151 |
> The flip side: as udev gets more and more complex, how could you be sure it |
152 |
> won't catastrophically fail one day, just like HAL? |
153 |
|
154 |
Educated guess ;) |
155 |
|
156 |
I have been using Linux since 1997. I lived through the OSS -> ALSA |
157 |
transition, the GNOME 1.0 -> GNOME 1.2 -> GNOME 2.0 -> GNOME 3.0 |
158 |
transition, the xine -> Mplayer -> Totem transition, the HAL -> no-HAL |
159 |
transition, and (of course) the mknod -> devfs -udev transition. |
160 |
|
161 |
I'm willing to bet yet another beer that udev will not have the fate HAL had. |
162 |
|
163 |
>> > Talk about double standards :-) |
164 |
>> |
165 |
>> When I hear Walt saying that mdev handles GNOME/KDE/XFCE/LVM2, you may |
166 |
>> say that. Right *now*, Walt says mdev doesn't handle those cases. |
167 |
>> |
168 |
> |
169 |
> Walt said that mdev doesn't work with LVM2, but then Alan said that actually |
170 |
> LVM2 works after booting. It just didn't work during booting. Suspiciously a |
171 |
> case of missing/misnamed dev nodes to me, easily fixable by adding some |
172 |
> mdev.conf rules. |
173 |
|
174 |
So, easily fix it. I'm not using it anyhow. |
175 |
|
176 |
>> Go and solve it then. I will keep using udev, which works right now, thank |
177 |
>> you. |
178 |
>> |
179 |
> |
180 |
> I am not using LVM, so I have no test case. But I certainly will pursue this |
181 |
> issue -- had you not derail the thread by slandering mdev with all your |
182 |
> might. |
183 |
|
184 |
I'm not slandering anyone; I'm just stating my opinion. mdev cannot do |
185 |
what udev does, and I believe the mdev developers agree with that |
186 |
(certainly Walt does). I don't see why that's "slandering". |
187 |
|
188 |
Don't take it personal man, relax. |
189 |
|
190 |
>> >> With all due respect, Alan (and this is completely sincere, in this |
191 |
>> >> list you are of the guys I respect the most), I believe you are |
192 |
>> >> thinking too small. |
193 |
>> >> |
194 |
>> > |
195 |
>> > With all due respect, I believe *you* are too defensive in regards to |
196 |
>> > udev. |
197 |
>> |
198 |
>> I'm not defending anything; just stating my opinion. You are free to |
199 |
>> disagree, of course. |
200 |
>> |
201 |
> |
202 |
> The way you write it, as if udev is the greatest thing since slice bread |
203 |
> while mdev is 'useless and destined to fail'? |
204 |
|
205 |
No, udev solves the general problem, mdev not. That's it. |
206 |
|
207 |
> Sounds like a fanboy rant to me :-) |
208 |
|
209 |
If you say so. Not the case, actually. |
210 |
|
211 |
>> Go and code if it's really easy and simple and doable. Me? I will |
212 |
>> stick with udev, 'cause it works. And it works *right now*, in all my |
213 |
>> use cases and even some I don't plan to have in the near future. |
214 |
>> |
215 |
> |
216 |
> If it's a case of missing node, it's *very* easy: Identify what node it's |
217 |
> being expected, identify what node was created by mdev, edit mdev.conf to |
218 |
> perform a rename+symlink. |
219 |
|
220 |
Then do it. My "slandering" (so you call it) should not matter. |
221 |
|
222 |
>> If someone is willing (and able) to do it, good for him/she/them. I'm |
223 |
>> sticking with udev, and if at some point mdev does everything udev |
224 |
>> does right now, I again bet a beer that the first would be as complex |
225 |
>> as the second. |
226 |
>> |
227 |
> |
228 |
> You are *totally* missing the point. |
229 |
|
230 |
I believe I'm not. |
231 |
|
232 |
> The point was never to make mdev as complex as udev. |
233 |
|
234 |
You *are* missing my point. My prediction is that if mdev ever handles |
235 |
all the cases udev does, mdev will be as complex as udev. I could be |
236 |
wrong, of course. But again, educated guess ;) |
237 |
|
238 |
> The point was to give people option by *not* requiring udev, but only |
239 |
> virtual/device-manager. |
240 |
|
241 |
And good for them. |
242 |
|
243 |
> Users no longer have to choose between two dichotomies, i.e., the omnipotent |
244 |
> udev vs the simplistic mdev. Instead, they can choose between the bloated |
245 |
> udev, or the lean mdev which *already can* cater for more complex behavior |
246 |
> if necessary. |
247 |
|
248 |
Bluetooth anybody? |
249 |
|
250 |
And relax man, this is friendly dicussion, not religious rethoric. |
251 |
|
252 |
Regards. |
253 |
-- |
254 |
Canek Peláez Valdés |
255 |
Posgrado en Ciencia e Ingeniería de la Computación |
256 |
Universidad Nacional Autónoma de México |