Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

["Canek Peláez Valdés" <caneko@gmail.com>]

On Wed, Mar 14, 2012 at 1:24 PM, Pandu Poluan <pandu@poluan.info> wrote:
>
> On Mar 15, 2012 1:22 AM, "Canek Peláez Valdés" <caneko@gmail.com> wrote:
>>
>> On Wed, Mar 14, 2012 at 12:03 PM, Pandu Poluan <pandu@poluan.info> wrote:
>> >
>> > On Mar 15, 2012 12:25 AM, "Canek Peláez Valdés" <caneko@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?

Whoa, relax man. We are discussing (or at least I'm trying) in a civil
manner the technical merits of two proposed solutions for a problem.
No need to get personal.

(And BTW, I've been using Gentoo since 2003, and I maintain an overlay
to use systemd without the need of having openrc/baselayout
installed).

>> > 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

Yeah. I agree with their decision. Read:

http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

> It *is* scalable. Ever tried du /usr?

Yeah, from time to time. Fail to see your point.

> The problem was -- is -- that package maintainers blindly put binaries
> required for booting into /usr

No problem with an intiramfs :D

>> > 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.

Again with the personal attacks; relax man. No need to get all worked out.

> 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)

Yeah, I'm gonna try that instead of udev, which works out of the box.
I'm gonna pass, thank you.

>> 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.

Relax, I'm not on a high chair; again, I'm just stating my opinion. I
have read the mail, I think the day it was posted. I don't buy it, for
all the reasons I have been saying.

>> > 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

:D

Actually, a Lego brick is a good analogy for mdev (in its current
state). It's a beautiful toy; but again, nobody has pointed out how to
make it work with bluetooth devices, for example. From Walt's mail
(his words, not mine):

"This revision includes some checking to see if your system can run
without udev.  In general, if you use any of...
* GNOME
* KDE
* XFCE
* lvm2
... you probably need udev, so mdev is not for you."

>> 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?

I doesn't work, out of the box, right now. Again, see Walt's mail.

> 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?

Educated guess ;)

I have been using Linux since 1997. I lived through the OSS -> ALSA
transition, the GNOME 1.0 -> GNOME 1.2 -> GNOME 2.0 -> GNOME 3.0
transition, the xine -> Mplayer -> Totem transition, the HAL -> no-HAL
transition, and (of course) the  mknod -> devfs -udev transition.

I'm willing to bet yet another beer that udev will not have the fate HAL had.

>> > 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.

So, easily fix it. I'm not using it anyhow.

>> 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.

I'm not slandering anyone; I'm just stating my opinion. mdev cannot do
what udev does, and I believe the mdev developers agree with that
(certainly Walt does). I don't see why that's "slandering".

Don't take it personal man, relax.

>> >> 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'?

No, udev solves the general problem, mdev not. That's it.

> Sounds like a fanboy rant to me :-)

If you say so. Not the case, actually.

>> 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.

Then do it. My "slandering" (so you call it) should not matter.

>> 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.

I believe I'm not.

> The point was never to make mdev as complex as udev.

You *are* missing my point. My prediction is that if mdev ever handles
all the cases udev does, mdev will be as complex as udev. I could be
wrong, of course. But again, educated guess ;)

> The point was to give people option by *not* requiring udev, but only
> virtual/device-manager.

And good for them.

> 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.

Bluetooth anybody?

And relax man, this is friendly dicussion, not  religious rethoric.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México