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

[Canek Peláez Valdés]

On Wed, Mar 14, 2012 at 12:03 PM, Pandu Poluan <pandu@××××××.info> wrote:
>
> 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.

udev already does it.

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

Yeah, right. And put LVM2 binaries in /bin. And wpa_supplicant (maybe
I need a wireless connected NFS share). And...

Not scalable. Doesn't solve the general case. You are seeing too small.

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

udev can do it *right now*, no hacks involved. Go and hack mdev until
it handles *ALL* the cases udev handles, and see how complex it gets.

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

Been there, tried that. What do you think devfs was? We tried this
path already: it doesn't work, it doesn't scale. You couple together
the device manager and the database handling and the firing of
associated scripts because that's the technical correct solution. It
*is* more complex, for sure, but so it's the general problem we are
trying to solve.

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

And guess what? I don't want a toy solution built with lego blocks. I
want a robust, general solution, that it is bound to work *now* and in
the future.

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

It's not my intention to "denigrate" anything. Just stating my opinion.

> Talk about double standards :-)

When I hear Walt saying that mdev handles GNOME/KDE/XFCE/LVM2, you may
say that. Right *now*, Walt says mdev doesn't handle those cases.

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

Go and solve it then. I will keep using udev, which works right now, thank you.

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

I'm not defending anything; just stating my opinion. You are free to
disagree, of course.

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

Go and code if it's really easy and simple and doable. Me? I will
stick with udev, 'cause it works. And it works *right now*, in all my
use cases and even some I don't plan to have in the near future.

> 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

You keep saying is easy/simple/doable; code talks. Right now, the guy
doing some coding and not only talking (Walter) says
GNOME/KDE/XFCE/LVM2 doesn't work with mdev. *Maybe* they could be made
to work with mdev, but someone has to actually *write the code* for
that to happen. Until then, talking is easy.

Right now, mdev is not enough, period. Maybe we can (as you yourself
say) "work around" the "problem", but that is work that someone has to
do.

If someone is willing (and able) to do it, good for him/she/them. I'm
sticking with udev, and if at some point mdev does everything udev
does right now, I again bet a beer that the first would be as complex
as the second.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México