Re: [gentoo-user] Beta test Gentoo with mdev instead of udev; version 5 - failure :-(

[Pandu Poluan]

On Mar 15, 2012 12:25 AM, "Canek Peláez Valdés" <caneko@×××××.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
> 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,