1 |
On Mar 15, 2012 1:22 AM, "Canek Peláez Valdés" <caneko@×××××.com> wrote: |
2 |
> |
3 |
> On Wed, Mar 14, 2012 at 12:03 PM, Pandu Poluan <pandu@××××××.info> wrote: |
4 |
> > |
5 |
> > On Mar 15, 2012 12:25 AM, "Canek Peláez Valdés" <caneko@×××××.com> |
6 |
wrote: |
7 |
> >> |
8 |
> > |
9 |
> > ---- >8 snip |
10 |
> > |
11 |
> >> |
12 |
> >> That if I connect a USB wi-fi dongle, and it appears with the name |
13 |
> >> wlan23, I want *every* time that dongle to have the wlan23 name .Good |
14 |
> >> luck doing that without a database. |
15 |
> >> |
16 |
> > |
17 |
> > That could -- should -- be handled by a script or a program that looks |
18 |
up |
19 |
> > the database, do the checks, and rename the node accordingly. |
20 |
> > |
21 |
> > All the device manager got to do is to plug in into the hotplug kernel |
22 |
knob, |
23 |
> > whereby it will be invoked on every hotplug event, and depending on the |
24 |
> > nature if the device (which, in your example, fits the pattern "wlan*") |
25 |
> > fires the script/program which performs the lookup+rename part. |
26 |
> > |
27 |
> > mdev can do that. |
28 |
> |
29 |
> udev already does it. |
30 |
> |
31 |
|
32 |
So does mdev. If writing a simple script is so distressing for you, why in |
33 |
the world are you using Gentoo, with all its manual labor? |
34 |
|
35 |
> > Put it under /bin |
36 |
> > |
37 |
> > Done. |
38 |
> |
39 |
> Yeah, right. And put LVM2 binaries in /bin. And wpa_supplicant (maybe |
40 |
> I need a wireless connected NFS share). And... |
41 |
> |
42 |
> Not scalable. Doesn't solve the general case. You are seeing too small. |
43 |
> |
44 |
|
45 |
*You* are not seeing _at all_. Witness how the Fedora devs want to merge |
46 |
/bin and /sbin |
47 |
|
48 |
It *is* scalable. Ever tried du /usr? |
49 |
|
50 |
The problem was -- is -- that package maintainers blindly put binaries |
51 |
required for booting into /usr |
52 |
|
53 |
> > The vast majority of Linux users, be they using PCs or smartphones, only |
54 |
> > need a mechanism to handle hotplugs. |
55 |
> > |
56 |
> > udev can do it, but so can mdev (with the help of helper |
57 |
scripts/programs). |
58 |
> |
59 |
> udev can do it *right now*, no hacks involved. Go and hack mdev until |
60 |
> it handles *ALL* the cases udev handles, and see how complex it gets. |
61 |
> |
62 |
|
63 |
If you're so afraid of doing things manually, you have no business using |
64 |
Gentoo in the first place. |
65 |
|
66 |
Here's a prototype script to ensure that certain NICs will always end up |
67 |
the way you want it named: |
68 |
|
69 |
#!/bin/sh |
70 |
mac="$( cat /proc/net/arp | awk -V dev="$MDEV" 'NR==1{next} $6==dev {print |
71 |
$4}')" |
72 |
name="$(awk -V mac="$mac" '$1==mac {print $2}')" |
73 |
[ "$name" ] && mv /dev/$MDEV /dev/$name |
74 |
exit 0 |
75 |
|
76 |
(Prototype, because I don't have access to a Linux box atm, so I can't test) |
77 |
|
78 |
> Been there, tried that. What do you think devfs was? We tried this |
79 |
> path already: it doesn't work, it doesn't scale. You couple together |
80 |
> the device manager and the database handling and the firing of |
81 |
> associated scripts because that's the technical correct solution. It |
82 |
> *is* more complex, for sure, but so it's the general problem we are |
83 |
> trying to solve. |
84 |
> |
85 |
|
86 |
If you step down from your high chair for awhile and read the busybox |
87 |
thread I've been linking, you'll know the difference. One of the emails in |
88 |
that thread explained it. |
89 |
|
90 |
> > udev is going the kitchen sink route. mdev stays the lego brick path. |
91 |
> |
92 |
> And guess what? I don't want a toy solution built with lego blocks. |
93 |
|
94 |
Obviously idioms went way over your head. |
95 |
|
96 |
If you're taking the "Lego brick" allegory as literal, then good luck with |
97 |
your kitchen sink. At least I know that with Lego bricks, amazing works of |
98 |
art have been created. :-P |
99 |
|
100 |
> I |
101 |
> want a robust, general solution, that it is bound to work *now* and in |
102 |
> the future. |
103 |
> |
104 |
|
105 |
So? What makes you think that in the future suddenly mdev stops working? |
106 |
|
107 |
The flip side: as udev gets more and more complex, how could you be sure it |
108 |
won't catastrophically fail one day, just like HAL? |
109 |
|
110 |
> > Talk about double standards :-) |
111 |
> |
112 |
> When I hear Walt saying that mdev handles GNOME/KDE/XFCE/LVM2, you may |
113 |
> say that. Right *now*, Walt says mdev doesn't handle those cases. |
114 |
> |
115 |
|
116 |
Walt said that mdev doesn't work with LVM2, but then Alan said that |
117 |
actually LVM2 works after booting. It just didn't work during booting. |
118 |
Suspiciously a case of missing/misnamed dev nodes to me, easily fixable by |
119 |
adding some mdev.conf rules. |
120 |
|
121 |
> Go and solve it then. I will keep using udev, which works right now, |
122 |
thank you. |
123 |
> |
124 |
|
125 |
I am not using LVM, so I have no test case. But I certainly will pursue |
126 |
this issue -- had you not derail the thread by slandering mdev with all |
127 |
your might. |
128 |
|
129 |
> >> With all due respect, Alan (and this is completely sincere, in this |
130 |
> >> list you are of the guys I respect the most), I believe you are |
131 |
> >> thinking too small. |
132 |
> >> |
133 |
> > |
134 |
> > With all due respect, I believe *you* are too defensive in regards to |
135 |
udev. |
136 |
> |
137 |
> I'm not defending anything; just stating my opinion. You are free to |
138 |
> disagree, of course. |
139 |
> |
140 |
|
141 |
The way you write it, as if udev is the greatest thing since slice bread |
142 |
while mdev is 'useless and destined to fail'? |
143 |
|
144 |
Sounds like a fanboy rant to me :-) |
145 |
|
146 |
> Go and code if it's really easy and simple and doable. Me? I will |
147 |
> stick with udev, 'cause it works. And it works *right now*, in all my |
148 |
> use cases and even some I don't plan to have in the near future. |
149 |
> |
150 |
|
151 |
If it's a case of missing node, it's *very* easy: Identify what node it's |
152 |
being expected, identify what node was created by mdev, edit mdev.conf to |
153 |
perform a rename+symlink. |
154 |
|
155 |
> If someone is willing (and able) to do it, good for him/she/them. I'm |
156 |
> sticking with udev, and if at some point mdev does everything udev |
157 |
> does right now, I again bet a beer that the first would be as complex |
158 |
> as the second. |
159 |
> |
160 |
|
161 |
You are *totally* missing the point. |
162 |
|
163 |
The point was never to make mdev as complex as udev. |
164 |
|
165 |
The point was to give people option by *not* requiring udev, but only |
166 |
virtual/device-manager. |
167 |
|
168 |
Users no longer have to choose between two dichotomies, i.e., the |
169 |
omnipotent udev vs the simplistic mdev. Instead, they can choose between |
170 |
the bloated udev, or the lean mdev which *already can* cater for more |
171 |
complex behavior if necessary. |
172 |
|
173 |
Rgds, |