On Thu, Jan 5, 2012 at 5:08 PM, Nicolas Sebrecht <nicolas.s-...@laposte.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
