On Mar 15, 2012 1:22 AM, "Canek Peláez Valdés" <can...@gmail.com> wrote:
>
> On Wed, Mar 14, 2012 at 12:03 PM, Pandu Poluan <pa...@poluan.info> wrote:
> >
> > On Mar 15, 2012 12:25 AM, "Canek Peláez Valdés" <can...@gmail.com>
wrote:
> >>
> >
> > ---- >8 snip
> >
> >>
> >> That if I connect a USB wi-fi dongle, and it appears with the name
> >> wlan23, I want *every* time that dongle to have the wlan23 name .Good
> >> luck doing that without a database.
> >>
> >
> > That could -- should -- be handled by a script or a program that looks
up
> > the database, do the checks, and rename the node accordingly.
> >
> > All the device manager got to do is to plug in into the hotplug kernel
knob,
> > whereby it will be invoked on every hotplug event, and depending on the
> > nature if the device (which, in your example, fits the pattern "wlan*")
> > fires the script/program which performs the lookup+rename part.
> >
> > mdev can do that.
>
> udev already does it.
>
So does mdev. If writing a simple script is so distressing for you, why in
the world are you using Gentoo, with all its manual labor?
> > Put it under /bin
> >
> > Done.
>
> Yeah, right. And put LVM2 binaries in /bin. And wpa_supplicant (maybe
> I need a wireless connected NFS share). And...
>
> Not scalable. Doesn't solve the general case. You are seeing too small.
>
*You* are not seeing _at all_. Witness how the Fedora devs want to merge
/bin and /sbin
It *is* scalable. Ever tried du /usr?
The problem was -- is -- that package maintainers blindly put binaries
required for booting into /usr
> > The vast majority of Linux users, be they using PCs or smartphones, only
> > need a mechanism to handle hotplugs.
> >
> > udev can do it, but so can mdev (with the help of helper
scripts/programs).
>
> udev can do it *right now*, no hacks involved. Go and hack mdev until
> it handles *ALL* the cases udev handles, and see how complex it gets.
>
If you're so afraid of doing things manually, you have no business using
Gentoo in the first place.
Here's a prototype script to ensure that certain NICs will always end up
the way you want it named:
#!/bin/sh
mac="$( cat /proc/net/arp | awk -V dev="$MDEV" 'NR==1{next} $6==dev {print
$4}')"
name="$(awk -V mac="$mac" '$1==mac {print $2}')"
[ "$name" ] && mv /dev/$MDEV /dev/$name
exit 0
(Prototype, because I don't have access to a Linux box atm, so I can't test)
> Been there, tried that. What do you think devfs was? We tried this
> path already: it doesn't work, it doesn't scale. You couple together
> the device manager and the database handling and the firing of
> associated scripts because that's the technical correct solution. It
> *is* more complex, for sure, but so it's the general problem we are
> trying to solve.
>
If you step down from your high chair for awhile and read the busybox
thread I've been linking, you'll know the difference. One of the emails in
that thread explained it.
> > udev is going the kitchen sink route. mdev stays the lego brick path.
>
> And guess what? I don't want a toy solution built with lego blocks.
Obviously idioms went way over your head.
If you're taking the "Lego brick" allegory as literal, then good luck with
your kitchen sink. At least I know that with Lego bricks, amazing works of
art have been created. :-P
> I
> want a robust, general solution, that it is bound to work *now* and in
> the future.
>
So? What makes you think that in the future suddenly mdev stops working?
The flip side: as udev gets more and more complex, how could you be sure it
won't catastrophically fail one day, just like HAL?
> > Talk about double standards :-)
>
> When I hear Walt saying that mdev handles GNOME/KDE/XFCE/LVM2, you may
> say that. Right *now*, Walt says mdev doesn't handle those cases.
>
Walt said that mdev doesn't work with LVM2, but then Alan said that
actually LVM2 works after booting. It just didn't work during booting.
Suspiciously a case of missing/misnamed dev nodes to me, easily fixable by
adding some mdev.conf rules.
> Go and solve it then. I will keep using udev, which works right now,
thank you.
>
I am not using LVM, so I have no test case. But I certainly will pursue
this issue -- had you not derail the thread by slandering mdev with all
your might.
> >> With all due respect, Alan (and this is completely sincere, in this
> >> list you are of the guys I respect the most), I believe you are
> >> thinking too small.
> >>
> >
> > With all due respect, I believe *you* are too defensive in regards to
udev.
>
> I'm not defending anything; just stating my opinion. You are free to
> disagree, of course.
>
The way you write it, as if udev is the greatest thing since slice bread
while mdev is 'useless and destined to fail'?
Sounds like a fanboy rant to me :-)
> Go and code if it's really easy and simple and doable. Me? I will
> stick with udev, 'cause it works. And it works *right now*, in all my
> use cases and even some I don't plan to have in the near future.
>
If it's a case of missing node, it's *very* easy: Identify what node it's
being expected, identify what node was created by mdev, edit mdev.conf to
perform a rename+symlink.
> If someone is willing (and able) to do it, good for him/she/them. I'm
> sticking with udev, and if at some point mdev does everything udev
> does right now, I again bet a beer that the first would be as complex
> as the second.
>
You are *totally* missing the point.
The point was never to make mdev as complex as udev.
The point was to give people option by *not* requiring udev, but only
virtual/device-manager.
Users no longer have to choose between two dichotomies, i.e., the
omnipotent udev vs the simplistic mdev. Instead, they can choose between
the bloated udev, or the lean mdev which *already can* cater for more
complex behavior if necessary.
Rgds,
