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 1S7bPy-0007mH-R8 for garchives@archives.gentoo.org; Tue, 13 Mar 2012 23:46:15 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D560EE0967; Tue, 13 Mar 2012 23:46:05 +0000 (UTC) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by pigeon.gentoo.org (Postfix) with ESMTP id 34762E0943 for ; Tue, 13 Mar 2012 23:44:52 +0000 (UTC) Received: (qmail 61267 invoked by uid 3782); 13 Mar 2012 23:44:51 -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:44:50 +0100 Received: (qmail 5490 invoked by uid 1000); 13 Mar 2012 23:43:54 -0000 Date: Tue, 13 Mar 2012 23:43:54 +0000 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-( Message-ID: <20120313234354.GG2536@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> <20120313230350.52973c84@hactar.digimed.co.uk> 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=us-ascii Content-Disposition: inline In-Reply-To: <20120313230350.52973c84@hactar.digimed.co.uk> 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 X-Archives-Salt: eacdb368-1fc7-450c-ba36-ce9e1fae2b42 X-Archives-Hash: f672de5825728729715096027008674e On Tue, Mar 13, 2012 at 11:03:50PM +0000, Neil Bothwick wrote: > On Tue, 13 Mar 2012 22:20:19 +0000, Alan Mackenzie wrote: > > > 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. Is there any need for this > > blurring? Having device nodes is essential to a linux system, and > > some programs use these nodes. Why must they be mashed together into a > > tasteless mush? Is there some advantage to this I haven't twigged yet? > I agree with you on this. The initial creation of device nodes belongs in > early startup, running arbitrary programs does not. > > > 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 the > > device node system rather than via the driver. Isn't that what drivers > > are for? > udev is not a device node system, it is a device manager. Requiring > drivers to handle it gets us into the same mess as Windows, where each > driver has to implement the same functionality itself. If a new modem is > released with a different USB ID, but using the same driver, your way > would require a new kernel, the current approach requires one line to be > added to a config file. Right! Now this is beginning to look like a beginning of an answer to my lack of understanding. ;-) This config file - is this the udev "rules"? Or am I getting mixed up with something else? > > > That's fine when you plug it into a running system, but when you boot > > > with it plugged in, it can trip over itself because the usb_modeswitch > > > executable is in /usr/sbin. > > Er, that's a different discussion altogether. ;-) > How so? It's central to the whole "when do we need /usr?" debate. I meant we'd already had a wide ranging discussion about early /usr. > > > 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". I still don't understand the basic > > concept driving this thing. My HDDs don't need rules - they just need a > > mapping from /dev/sd[ab] into device 8/0 and 8/16, and the appropriate > > drivers built into my kernel. > "I don't need it so no one needs it". It sounds like what you need is > mdev, but many people want or need more from a device manager. There are > many more and varied devices than simple hard disks. That's not fair. I'm convinced _I_ don't need more than mdev; I'm still trying to get a handle on why other devices need more. > > Am I being stupid? Despite your example above, I still don't see what > > udev is about, why it's necessary, or even why it's advantageous. > What you don't see is why *you* need it, and that's fair enough. Just > consider that it does things that others need, even if you don't. I'm not trying to be combative. In fact, I'm trying not to be combative. I'm just trying to get some sort of grasp on what it is I don't yet see. I want to understand what udev offers that mdev can't, and I'm getting very frustrated about not being able to find the right questions to ask. > But I still think the requirement for /usr to be mounted is a lazy, if > understandable, solution to the way udev's operations are implemented. > After all, the vast majority of PC Linux installations out there already > use an initramfs. They do, and I understand that one - it is the necessity to have a one-size-fits-all kernel in a binary distribution. As gentooers, we don't suffer that constraint, therefore we don't (and shouldn't) need an initramfs, unless we want one. Anyhow, it's now European bed time, one hour more for me than for you, so thanks for the discussion and let's call it quits for today. :-) > -- > Neil Bothwick > How do I set my laser printer to stun? How about a picture of Marilyn Monroe? -- Alan Mackenzie (Nuremberg, Germany).