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 1S7and-00025x-Du for garchives@archives.gentoo.org; Tue, 13 Mar 2012 23:06:37 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 60D03E0CBA; Tue, 13 Mar 2012 23:06:24 +0000 (UTC) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by pigeon.gentoo.org (Postfix) with ESMTP id 2B21AE0C4A for ; Tue, 13 Mar 2012 23:04:56 +0000 (UTC) Received: (qmail 58351 invoked by uid 3782); 13 Mar 2012 23:04:56 -0000 Received: from acm.muc.de (pD951B273.dip.t-dialin.net [217.81.178.115]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 14 Mar 2012 00:04:53 +0100 Received: (qmail 5374 invoked by uid 1000); 13 Mar 2012 23:03:58 -0000 Date: Tue, 13 Mar 2012 23:03:58 +0000 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-( Message-ID: <20120313230358.GF2536@acm.acm> References: <20120312092432.GA2959@acm.acm> <20120313073306.GC23544@waltdnes.org> <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> 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 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 79277cc5-8d83-4e6b-ab04-a2e2c9461c84 X-Archives-Hash: 787bcb0f6a1e56b719d443a8737c309c On Tue, Mar 13, 2012 at 04:38:08PM -0600, Canek Pel=E1ez Vald=E9s wrote: > On Tue, Mar 13, 2012 at 4:20 PM, Alan Mackenzie wrote: > > Hello, Neil. > > On Tue, Mar 13, 2012 at 09:33:30PM +0000, Neil Bothwick wrote: > >> On Tue, 13 Mar 2012 21:07:37 +0000, Alan Mackenzie wrote: > >> > But I really meant what functionality udev has that mdev lacks. =A0= For > >> > example, mdev this morning recognised my USB stick being inserted,= and > >> > created /dev/sdc for it. > >> udev does a *lot* more than that, for example the persistent naming = of > >> network interfaces. More significantly, it can run programs based on > >> device rules. > > This is where I start getting unhappy. =A0Is there any need for this > > blurring? =A0Having device nodes is essential to a linux system, and > > some programs use these nodes. =A0Why must they be mashed together in= to a > > tasteless mush? =A0Is there some advantage to this I haven't twigged = yet? > >> For example, usb_modeswitch installs a udev rule to switch a 3G USB > >> modem from CD to modem mode, without which it won't work. > > Same question as above: why does that switching have to be done via t= he > > device node system rather than via the driver. =A0Isn't that what dri= vers > > are for? > >> That's fine when you plug it into a running system, but when you boo= t > >> with it plugged in, it can trip over itself because the usb_modeswit= ch > >> executable is in /usr/sbin. > > Er, that's a different discussion altogether. =A0;-) > >> You could use this to argue that /usr should be mounted before udev = is > >> started, but you could just as well use it to argue that udev should= not > >> be trying to run such rules at the boot runlevel. > > Or that udev shouldn't have "rules". =A0I still don't understand the = basic > > concept driving this thing. =A0My HDDs don't need rules - they just n= eed a > > mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriat= e > > drivers built into my kernel. > > Am I being stupid? =A0Despite your example above, I still don't see w= hat > > udev is about, why it's necessary, or even why it's advantageous. > IMHO, the thing that most people are missing is the fact that neither > udev nor Linux "got complicated". The computing world itself "got > complicated". Not really. It's been getting more complicated since long before I starting working in it in 1980. Nothing's changed there. > We have Linux running in the same beige machines it has been running > since 1991, but it also runs in TVs, tablets, cellphones, fridges, > cars, ebook readers, and (soon enough, I'm sure) the kitchen sink. > This devices behave very differently from our old and beloved beige > boxen. Not at the level of needing device nodes under /dev and drivers connected to them, they haven't. > They need to handle lots of different hardware comming and going, via > USB, Firewire, Bluetooth, WIMAX, and who knows what else in the future. Yes. That's why there's a generic facility for building arbitrary drivers into a kernel. That's not new either. > The principal idea behind udev, is that we *don't* kown (we *can't* > know) what hardware this or that machine is gonna have at some point. > And we want the machine (and the new hardware) to "just work" when > they are connected. Huh? What's that to do with udev? You're talking at far too high a level of abstraction. The new hardware will "just work" if there are the correct drivers built in. That's as true of udev as it is of mdev as it is of the old static /dev with mknod. [ .... ] > So, yeah, it's more complicated. The world got complicate; better get > used to it. You're bluffing, aren't you? You really don't have any more idea than I do about the technical motivation for udev, do you? > Regards. > --=20 > Canek Pel=E1ez Vald=E9s > Posgrado en Ciencia e Ingenier=EDa de la Computaci=F3n > Universidad Nacional Aut=F3noma de M=E9xico --=20 Alan Mackenzie (Nuremberg, Germany).