From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1S7tpD-000735-SY for garchives@archives.gentoo.org; Wed, 14 Mar 2012 19:25:33 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 46710E0885; Wed, 14 Mar 2012 19:25:21 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) by pigeon.gentoo.org (Postfix) with ESMTP id 8260AE071C for ; Wed, 14 Mar 2012 19:24:22 +0000 (UTC) Received: from mail-we0-f181.google.com ([74.125.82.181]) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1S7to8-000Evm-Uj for gentoo-user@lists.gentoo.org; Thu, 15 Mar 2012 02:24:25 +0700 Received: by werm13 with SMTP id m13so2516132wer.40 for ; Wed, 14 Mar 2012 12:24:18 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.52.88.103 with SMTP id bf7mr2773731vdb.72.1331753057384; Wed, 14 Mar 2012 12:24:17 -0700 (PDT) Received: by 10.220.58.200 with HTTP; Wed, 14 Mar 2012 12:24:16 -0700 (PDT) Received: by 10.220.58.200 with HTTP; Wed, 14 Mar 2012 12:24:16 -0700 (PDT) In-Reply-To: References: <20120313130534.GB3457@acm.acm> <20120313190052.GA2430@waltdnes.org> <20120313194727.GB2536@acm.acm> <20120313210737.GD2536@acm.acm> <20120313213330.78c5ebf7@digimed.co.uk> <20120313222019.GE2536@acm.acm> <20120313230358.GF2536@acm.acm> <20120314151620.GB24395@acm.acm> Date: Thu, 15 Mar 2012 02:24:16 +0700 Message-ID: Subject: Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-( From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=20cf307f3c04e9f80a04bb38eb17 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Archives-Salt: 101e7eea-f2e8-459a-b383-ced8c2bbf6c9 X-Archives-Hash: c404aa7783ec5bf54d9eaa6b7eed8e38 --20cf307f3c04e9f80a04bb38eb17 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mar 15, 2012 1:22 AM, "Canek Pel=C3=A1ez Vald=C3=A9s" = wrote: > > On Wed, Mar 14, 2012 at 12:03 PM, Pandu Poluan wrote: > > > > On Mar 15, 2012 12:25 AM, "Canek Pel=C3=A1ez Vald=C3=A9s" 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, onl= y > > 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=3D"$( cat /proc/net/arp | awk -V dev=3D"$MDEV" 'NR=3D=3D1{next} $6=3D= =3Ddev {print $4}')" name=3D"$(awk -V mac=3D"$mac" '$1=3D=3Dmac {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, --20cf307f3c04e9f80a04bb38eb17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 15, 2012 1:22 AM, "Canek Pel=C3=A1ez Vald=C3=A9s" <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=C3=A1ez Vald=C3=A9s&quo= t; <caneko@gmail.com> wrote:<= br> > >>
> >
> > ---- >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 na= me .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 k= ernel 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 &q= uot;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<= br> > I need a wireless connected NFS share). And...
>
> Not scalable. Doesn't solve the general case. You are seeing too s= mall.
>

*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 r= equired for booting into /usr

> > The vast majority of Linux users, be they using PCs or smartph= ones, 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<= br> > it handles *ALL* the cases udev handles, and see how complex it gets.<= br> >

If you're so afraid of doing things manually, you have no business u= sing Gentoo in the first place.

Here's a prototype script to ensure that certain NICs will always en= d up the way you want it named:

#!/bin/sh
mac=3D"$( cat /proc/net/arp | awk -V dev=3D"$MDEV" 'NR= =3D=3D1{next} $6=3D=3Ddev {print $4}')"
name=3D"$(awk -V mac=3D"$mac" '$1=3D=3Dmac {print $2}= 9;)"
[ "$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 to= gether
> 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 ar= e
> trying to solve.
>

If you step down from your high chair for awhile and read the busybox th= read I've been linking, you'll know the difference. One of the emai= ls in that thread explained it.

> > udev is going the kitchen sink route. mdev stays the lego bric= k 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, the= n 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.<= br> >

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 you= r 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 a= re
> >> thinking too small.
> >>
> >
> > With all due respect, I believe *you* are too defensive in regard= s 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 :-)=C2=A0

> Go and code if it's really easy and simple and doable. Me? I wi= ll
> 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<= br> > 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 vi= rtual/device-manager.

Users no longer have to choose between two dichotomies, i.e., the omnipo= tent udev vs the simplistic mdev. Instead, they can choose between the bloa= ted udev, or the lean mdev which *already can* cater for more complex behav= ior if necessary.

Rgds,

--20cf307f3c04e9f80a04bb38eb17--