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

[Michael Mol]

On Thu, Jan 5, 2012 at 5:08 PM, Nicolas Sebrecht
<nicolas.s-dev@×××××××.net> wrote:
> On Thu, Jan 05, 2012 at 02:20:21PM -0500, Michael Mol wrote:
>
>> FWIW, I had a /dev/cdrom symlink long before *devfs* even existed, let
>> alone udev.
>
> We are not looking for device paths that existed berfore udev. Actually,
> most of them exist since much more time than udev. It's not relevant at
> all.

You missed my point. My point was that udev wasn't needed to resolve
the use case you described, that stable solutions to such cases
preceded udev, and so udev wasn't a necessary tool to solve them.

>
>> Also, ethN numberings are generally stable until and unless you do
>> some strange BIOS tweaking or hardware changes, and should be able to
>> be stabilized in the event the instability comes from some racy module
>> loading mechanism.
>
> This is not true. I've had computers in hands where network cards could
> change of names without any BIOS tunning.

Did this happen after a kernel update or a change to your kernel
configuration? A software update? A change in the set of enabled
modules, or which were built-in vs built as modules?

In any production server environment, I would assume you're already
watching the thing like a hawk and verifying that the thing comes up
properly after a reboot. Reboots should be very, very rare things. I
try to do things more or less correctly on a high-profile machine, and
I'm still giddy when the once-in-a-blue-moon reboot doesn't break
anything.

> BIOS is a executed program and
> the way each is implemented can guarantee *or not* to have the
> conditions for persistent NIC names on Linux.

What you're saying is that NIC stability is dependent on how the OEM
built the BIOS and software. I'll posit there may be strange NICs out
there which can't be initialized within a deterministic time frame
without some external factor such as a link handshake. If this were a
common behavior for a piece of hardware though, I'd consider it
indicative of shoddy quality, and would want to replace it.
Regardless, it's resolvable in software without using a tool that
imposes significant restrictions on system structure.

>
>> udev's attempts at stabilizing network interfaces have made things
>> worse more often than I've heard of it making them better. Hit any
>> search engine for "eth0 missing 70-persistent-net.rules".
>
> It's fully expected and required. Persistent naming can work if you have
> a configuration for that somewhere. I see nothing worse here.

One week, I helped no fewer than five people who ran afoul of the
70-persistent-net.rules file, and didn't know why their eth0
disappeared. These weren't newbie Linux users, either. Some knew their
way around GNOME better than I still do, and they mostly knew their
way around the shell. Some were networking professionals pulling more
than I do.

I'd wager the vast majority of systems out there have devices named as
'ethN' for wired connections, and 'wlanN', 'athN' or whatever for
wireless connections. And that the vast majority of those systems have
one or fewer wired connection ports. And that the further vast
majority of those don't have customized 70-persistent-net.rules files
as you and I have. If that's true, then the persistent-net rules
behavior currently harms more users than it benefits.

> But I see
> an improvement to let me tune the NIC names if I need to. I have routers
> with *lot of* NIC cards where this feature is very usefull (expressive
> names are much better than ethX).

I, too, noted this as a potential advantage of udev. On my router, I
have five interfaces. 'wan', 'he-tunnel', lan, wifi, lo and 'tun0'.
tun0 is only so-named because it's an OpenVPN thing I haven't bothered
to change. I've tried to advocate use this feature of udev.

But I administer my router the way I like to. Most people I've pointed
toward this capability just go "Meh. I have a list of interfaces and
what they're for." even when they already have udev.

-- 
:wq