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 1S7uA9-0002B0-1K for garchives@archives.gentoo.org; Wed, 14 Mar 2012 19:47:09 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 892FAE0AA9; Wed, 14 Mar 2012 19:47:00 +0000 (UTC) Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by pigeon.gentoo.org (Postfix) with ESMTP id CFA7AE0605 for ; Wed, 14 Mar 2012 19:45:56 +0000 (UTC) Received: by dadp12 with SMTP id p12so3420225dad.11 for ; Wed, 14 Mar 2012 12:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=GPqh4YFODcM4H8jN2QnhrRpqC8rYnTEp1E98o/5BUZQ=; b=r1VxT5yfMJR6l7TrrHvLfGS0QDu/RKNIv6ppOQevpNCZv8BXXXUFrnULsrTAxsYN6o HZukIc1DSsp0XDBsmiR4zswlEwc1AhchZzz1GYC1lXE/u9q4Uull8PzOQlBkFCCp4PZ7 AqlQXxycRAvM8HQZakY19cnkwtByBRDLF283MD8VlDK96av5kc43DGFlBejWypiGUnbM dMhxtRZsbBx3uFgu7X61MhxDwm40/KZENn6uIg20FXtlNWKLBdfcQi5LBV5YzohqkphF wFk11WO1etb5VbXR6FmquW64uCkYoQBb4QAbidSESECGwIFlfe0yEPkMbMPfiVQer2Y6 xycA== 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.68.203.74 with SMTP id ko10mr4313054pbc.125.1331754356038; Wed, 14 Mar 2012 12:45:56 -0700 (PDT) Received: by 10.68.197.41 with HTTP; Wed, 14 Mar 2012 12:45:55 -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: Wed, 14 Mar 2012 13:45:55 -0600 Message-ID: Subject: Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-( From: =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw6lz?= To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 030041e6-eb84-4470-b9f4-1fbf51084ac5 X-Archives-Hash: bb790b0addca94faefa59a1aa62acdf7 On Wed, Mar 14, 2012 at 1:24 PM, Pandu Poluan wrote: > > 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 th= e >> > 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 i= n > 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, on= ly >> > 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=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 te= st) 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 thr= ead > 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 wit= h > your kitchen sink. At least I know that with Lego bricks, amazing works o= f > 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 ha= d. >> > 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 actua= lly > LVM2 works after booting. It just didn't work during booting. Suspiciousl= y 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, tha= nk >> you. >> > > I am not using LVM, so I have no test case. But I certainly will pursue t= his > 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 omnipot= ent > udev vs the simplistic mdev. Instead, they can choose between the bloated > udev, or the lean mdev which *already can* cater for more complex behavio= r > if necessary. Bluetooth anybody? And relax man, this is friendly dicussion, not religious rethoric. Regards. --=20 Canek Pel=C3=A1ez Vald=C3=A9s Posgrado en Ciencia e Ingenier=C3=ADa de la Computaci=C3=B3n Universidad Nacional Aut=C3=B3noma de M=C3=A9xico