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 1S7sYq-0000Mt-Ln for garchives@archives.gentoo.org; Wed, 14 Mar 2012 18:04:33 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 00F52E0AA4; Wed, 14 Mar 2012 18:04:18 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) by pigeon.gentoo.org (Postfix) with ESMTP id 2EC19E0A6C for ; Wed, 14 Mar 2012 18:03:10 +0000 (UTC) Received: from mail-vx0-f181.google.com ([209.85.220.181]) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1S7sXY-004C1t-Ew for gentoo-user@lists.gentoo.org; Thu, 15 Mar 2012 01:03:12 +0700 Received: by vcge1 with SMTP id e1so2613465vcg.40 for ; Wed, 14 Mar 2012 11:03:06 -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.28.4 with SMTP id x4mr2598943vdg.4.1331748186729; Wed, 14 Mar 2012 11:03:06 -0700 (PDT) Received: by 10.220.58.200 with HTTP; Wed, 14 Mar 2012 11:03:06 -0700 (PDT) Received: by 10.220.58.200 with HTTP; Wed, 14 Mar 2012 11:03:06 -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 01:03:06 +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=20cf30780c8499ae6a04bb37c9d2 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: 0c0a17c7-a0c6-4382-adbe-1e80f7f4270e X-Archives-Hash: c4c92a61303392b9d41f574bb861232b --20cf30780c8499ae6a04bb37c9d2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. > Bluetooth keyboards. Done, you made my system unbootable when I need > to run fsck by hand after a power failure. > Put it under /bin Done. > Alan, the "vast majority" of Linux users right now are phone users. > That was my initial point some mails ago. What *you* believe are > "regular" users (people like you, or maybe even me), stopped being > true a couple of years ago. The days of the Unix admin and workstation > user are going the way of the dodo. > > At least, that's how I see it. > The vast majority of Linux users, be they using PCs or smartphones, only need a mechanism to handle hotplugs. udev can do it, but so can mdev (with the help of helper scripts/programs). > Again, think about phones. And tablets. And TVs. And > [insert-here-cool-gadgets-from-the-future]. > See above. > No, it's not a matter of "that's the way forward". It's a matter of > trying to solve the general problem. And since the general solution > also solves the simple cases, I don't see a reason to waste my > time/resources in a solution that in the end will not solve the > general problem. > It will always be simpler -- and easier to debug -- if we separate the hotplug handler (whose function is merely to create a dev node with the proper permissions and (optionally) fire up a 'configurator') from the configurator itself. udev is going the kitchen sink route. mdev stays the lego brick path. > Of course, as I have been saying from the beginning, this is > OpenSource. Want to pour some effort into solving the simple cases > that will not help all the community, and that it will only help in > fact a minority, that's your prerogative (and Walt's, and Vapier's, > and everyone else that don't like the "complex" but complete > solution). Go nuts with it if you want. > The code is there; it's called mdev. But your emails are nothing short of denigrating the code. Talk about double standards :-) > But please don't dismiss the general solution as "unnecessary" complex > when it's not the case, and don't think that the "simple" setups > (whatever that means) are the majority. Again, think phones and > tablets: those *are* the majority. > Again, see above. > Oh, for sure you can modify LVM2 to work under mdev. Also > GNOME/KDE/XFCE, and everything under the sun. You have the source; you > can do *anything* you want with it. > > But the effort wasted^^^^^Hpoured in that excercise will only serve a > handful of users, and it will be never accepted upstream, because > upstream is (rightfully) concerned with the general problem. > And as I have explained, based on what Alan had posted, LVM2 (for an example) probably only needs certain device nodes to exist, while mdev's default behavior is to not change anything unless explicitly told. Solvable easily, IMO. > I'm more interested in the general solution that will work not only > for my current machines, but also for the ones I'm planning to have in > the future. I'm dying to get a tablet where I can put GNOME 3 on it; I > can bet you another beer that mdev will be not enough to handle that. > Unfortunately I don't have any Gentoo with GUI, so I can't take up on your offer :-( > 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. > Right now Linux runs in my phone, my TV's, my routers and every > computer I own. I have a couple of Windows installations, which I use > once or twice every three months (I ported a PyGTK program to Windows > last week, so I had to boot into Windows for the first time this > year). I want Linux running on *everything*, and what is more: I don't > want android in my handhelds, I want the full GNOME experience. > > To accomplish that we need udev; mdev it's just not enough. > Again, not necessarily. What exactly in Gnome requires udev? Is it merely expecting some device nodes to exist while mdev's default behavior doesn't do that? That would be simple to solve. A bit more difficult is if Gnome communicates with udev via libudev; but busybox devs have looked into the code of libudev, and found that the functions provided by that lib is can be emulated relatively quickly [1]. But he then added that he won't do that, because that would make busybox too complex. [1] http://lists.busybox.net/pipermail/busybox/2011-September/076689.html Again, it's a matter of perspective. We can work around the problem by having the emulated libudev call mdev indirectly via an "mdev helper program", thus not needing mdev to be a kitchen sink. In fact, a post [2] slightly tangential to the thread of the above post, did just that: provide a way for mdev to be able to link onto netlink without having to make mdev a daemon. [2] http://lists.busybox.net/pipermail/busybox/2011-September/076740.html Rgds, --20cf30780c8499ae6a04bb37c9d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 15, 2012 12:25 AM, "Canek Pel=C3=A1ez Vald=C3=A9s" <caneko@gmail.com> 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<= br> > luck doing that without a database.
>

That could -- should -- be handled by a script or a program that looks u= p 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 k= nob, 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.

> Bluetooth keyboards. Done, you made my system unbootable when I nee= d
> to run fsck by hand after a power failure.
>

Put it under /bin

Done.

> Alan, the "vast majority" of Linux users right now are ph= one users.
> That was my initial point some mails ago. What *you* believe are
> "regular" users (people like you, or maybe even me), stopped= being
> true a couple of years ago. The days of the Unix admin and workstation=
> user are going the way of the dodo.
>
> At least, that's how I see it.
>

The vast majority of Linux users, be they using PCs or smartphones, only= need a mechanism to handle hotplugs.

udev can do it, but so can mdev (with the help of helper scripts/program= s).

> Again, think about phones. And tablets. And TVs. And
> [insert-here-cool-gadgets-from-the-future].
>

See above.

> No, it's not a matter of "that's the way forward"= . It's a matter of
> trying to solve the general problem. And since the general solution > also solves the simple cases, I don't see a reason to waste my
> time/resources in a solution that in the end will not solve the
> general problem.
>

It will always be simpler -- and easier to debug -- if we separate the h= otplug handler (whose function is merely to create a dev node with the prop= er permissions and (optionally) fire up a 'configurator') from the = configurator itself.

udev is going the kitchen sink route. mdev stays the lego brick path.

> Of course, as I have been saying from the beginning, this is
> OpenSource. Want to pour some effort into solving the simple cases
> that will not help all the community, and that it will only help in > fact a minority, that's your prerogative (and Walt's, and Vapi= er's,
> and everyone else that don't like the "complex" but comp= lete
> solution). Go nuts with it if you want.
>

The code is there; it's called mdev. But your emails are nothing sho= rt of denigrating the code.

Talk about double standards :-)

> But please don't dismiss the general solution as "unnecess= ary" complex
> when it's not the case, and don't think that the "simple&= quot; setups
> (whatever that means) are the majority. Again, think phones and
> tablets: those *are* the majority.
>

Again, see above.

> Oh, for sure you can modify LVM2 to work under mdev. Also
> GNOME/KDE/XFCE, and everything under the sun. You have the source; you=
> can do *anything* you want with it.
>
> But the effort wasted^^^^^Hpoured in that excercise will only serve a<= br> > handful of users, and it will be never accepted upstream, because
> upstream is (rightfully) concerned with the general problem.
>

And as I have explained, based on what Alan had posted, LVM2 (for an exa= mple) probably only needs certain device nodes to exist, while mdev's d= efault behavior is to not change anything unless explicitly told.

Solvable easily, IMO.

> I'm more interested in the general solution that will work not = only
> for my current machines, but also for the ones I'm planning to hav= e in
> the future. I'm dying to get a tablet where I can put GNOME 3 on i= t; I
> can bet you another beer that mdev will be not enough to handle that.<= br> >

Unfortunately I don't have any Gentoo with GUI, so I can't take = up on your offer :-(

> 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 ud= ev.

> Right now Linux runs in my phone, my TV's, my routers and every=
> computer I own. I have a couple of Windows installations, which I use<= br> > once or twice every three months (I ported a PyGTK program to Windows<= br> > last week, so I had to boot into Windows for the first time this
> year). I want Linux running on *everything*, and what is more: I don&#= 39;t
> want android in my handhelds, I want the full GNOME experience.
>
> To accomplish that we need udev; mdev it's just not enough.
>

Again, not necessarily. What exactly in Gnome requires udev? Is it merel= y expecting some device nodes to exist while mdev's default behavior do= esn't do that? That would be simple to solve.

A bit more difficult is if Gnome communicates with udev via libudev; but= busybox devs have looked into the code of libudev, and found that the func= tions provided by that lib is can be emulated relatively quickly [1]. But h= e then added that he won't do that, because that would make busybox too= complex.

[1] http://lists.busybox.net/pipermail/busybox/2011-September/076= 689.html

Again, it's a matter of perspective. We can work around the problem = by having the emulated libudev call mdev indirectly via an "mdev helpe= r program", thus not needing mdev to be a kitchen sink.

In fact, a post [2] slightly tangential to the thread of the above post,= did just that: provide a way for mdev to be able to link onto netlink with= out having to make mdev a daemon.

[2] http://lists.busybox.net/pipermail/busybox/2011-September/076= 740.html

Rgds,

--20cf30780c8499ae6a04bb37c9d2--