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 <gentoo-user+bounces-136316-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1S7pyD-0003QE-52
	for garchives@archives.gentoo.org; Wed, 14 Mar 2012 15:18:33 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 182B8E0982;
	Wed, 14 Mar 2012 15:18:19 +0000 (UTC)
Received: from mail.muc.de (colin.muc.de [193.149.48.1])
	by pigeon.gentoo.org (Postfix) with ESMTP id DE622E092A
	for <gentoo-user@lists.gentoo.org>; Wed, 14 Mar 2012 15:17:20 +0000 (UTC)
Received: (qmail 49979 invoked by uid 3782); 14 Mar 2012 15:17:19 -0000
Received: from acm.muc.de (pD951AD60.dip.t-dialin.net [217.81.173.96]) by
	colin.muc.de (tmda-ofmipd) with ESMTP;
	Wed, 14 Mar 2012 16:17:17 +0100
Received: (qmail 24644 invoked by uid 1000); 14 Mar 2012 15:16:20 -0000
Date: Wed, 14 Mar 2012 15:16:20 +0000
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Beta test Gentoo with mdev instead of udev;
	version 5 - failure :-(
Message-ID: <20120314151620.GB24395@acm.acm>
References: <20120313130534.GB3457@acm.acm>
	<20120313190052.GA2430@waltdnes.org>
	<20120313194727.GB2536@acm.acm>
	<CADPrc83mmaeybgdEb0phBrp=fBcF3EWkpZawp0Mo8wpvDje5NQ@mail.gmail.com>
	<20120313210737.GD2536@acm.acm>
	<20120313213330.78c5ebf7@digimed.co.uk>
	<20120313222019.GE2536@acm.acm>
	<CADPrc82SPiqxmKMf5aVGZtaXG6d_X17S6AWbx=pjnJKLTZJM-A@mail.gmail.com>
	<20120313230358.GF2536@acm.acm>
	<CADPrc80ejwk+DqysM3K-fmsjBgybfZjrHeYKHEoJ+bMigCg6HQ@mail.gmail.com>
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
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: <CADPrc80ejwk+DqysM3K-fmsjBgybfZjrHeYKHEoJ+bMigCg6HQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Delivery-Agent: TMDA/1.1.12 (Macallan)
From: Alan Mackenzie <acm@muc.de>
X-Primary-Address: acm@muc.de
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 728b9a51-4045-450d-8791-eae23c36ddc8
X-Archives-Hash: ff5336a2851d9782859bdfad25332356

Hello, Canek

On Tue, Mar 13, 2012 at 06:07:32PM -0600, Canek Pel=E1ez Vald=E9s wrote:
> On Tue, Mar 13, 2012 at 5:03 PM, Alan Mackenzie <acm@muc.de> wrote:

> >=A0The new hardware will "just work" if there are the correct drivers
> >built in. =A0That's as true of udev as it is of mdev as it is of the o=
ld
> >static /dev with mknod.

> No, it is not. You are letting out the sine qua non of the matter: the
> device has to be built, *and the /dev file should exists*. I hope you
> are not suggesting that we put *ALL* the possible files under /dev,
> because that was the idea before devfs, and it doesn't work *IN
> GENERAL*.

Previously you made appropriate /dev entries with mknod, giving the
device major and minor numbers as parameters.  This appeared to work in
general - I'm not aware of any device it didn't work for.

> So, you need something to handle device files on /dev, so you don't
> need every possible device file for every possible piece of hardware.
> But then you want to handle the same device with the same device name,
> so you need some kind of database. Then for the majority of users,
> they want to see *something* happen when they connect aa piece of
> hardware to their computers.

That happened under the old static /dev system.  What was that /dev
system, if not a database matching /dev names to device numbers?  I'm not
sure what you mean by "same device" and "same device name".

> So you need to handle the events associated with the connections (or
> discovery, for things like Bluetooth) of the devices, and since udev is
> already handling the database and the detection of
> connections/discovery, I agree with the decision of leting udev to
> execute programs when something gets connected. You could get that
> function in another program, but you are only moving the problem, *and
> it can also happen very early at boot time*, so lets udev handle it all
> the time.

Early in boot time, you only need things like disk drives, graphic cards
and keyboards.  Anything else can be postponed till late boot time.

> I hope you see where I'm going. As I said before, mdev could (in
> theory) do the same that udev does. But then it will be as complicated
> as udev, *because it is a complicated problem* in general. And I again
> use my fuel injection analogy: it is not *necessary*. It is just very
> damn convenient.

It may be a complicated problem in general, but many people do not need
that generality.  I suspect the vast majority don't need it.  Neither the
typical desktop, the typical server, nor typical embedded devices like
routers.

> I have a really time understanding why you don't see the complexity on
> the problem. I explained above: it is a complicated problem (when
> dealing with the general case), and therefore the (general) solution is
> bound to be also complicated.

I've had a hard time understanding, because up till now, nobody's
described the problem in detail - there's only been hand-waving.

> You want it simple? Tha'ts fine, it is possible. It's just that it
> will not solve the general problem, just a very specific subset of it.

That subset used by the vast majority of Linux users.  And yes, I do want
it simple, because elegant simplicity is the best way, IMAO.  You, on the
other hand, seem to love complicated solutions because they are "the way
forward".  We'll have to agree to disagree on this one.

> Just as mdev is doing; Walt just posted an email explaining that if
> you use GNOME, KDE, XFCE, or LVM2, mdev is not for you.

Walter is, I believe, mistaken here.  I can mount and use my LVM2
partitions.  Gnome looks like it comes up OK, but that could be moot,
since right now I haven't got keyboard/mouse drivers under the X server.

> I will not be surprised if in the future the list of programs "not for
> mdev" only grows.

There's a difference between "needed by portage" and "doesn't work under
mdev".  As I say, it will all be moot if the evdev driver won't work
under mdev.

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