On Thu, May 26, 2011 at 15:16, Marco d'Itri <md@xxxxxxxx> wrote: > On May 25, Kay Sievers <kay.sievers@xxxxxxxx> wrote: > >> We can not rename network devices in the kernel namespace (ethX) >> reliably. It's impossible to get right to rename in a conflicting >> namespace while kernel modules are loaded. > Can you tell me more about this? Because it worked well enough for the > last last 5 years. It does not fit my idea of "well enough", quite the opposite. The most important, it does not really solve a problem, but creates a lot of new ones. The whole idea of *automatic rules* and *persistence in the file system* is wrong. Stuff that requires static names requires *manual* configuration anyway, stuff that does not require static names, does not need the crappy automagic we do. You race against the kernel creating new interfaces, while we are in progress renaming devices. A game we can never win. We actually have real bugs for that, and can't solve them properly ever. Renaming stuff in the same namespace without global locks is never going to work, hence we need to stop pretending we can. It does not scale. If you have thousands of interfaces, the file will just be a total mess. People with boxes to 'test' stuff get thousands of dead rule lines, one for every new device that gets plugged in. It's just wrong to do that. A said earlier, it was a mistake to ever try to do *automatic* rule creation. We are absolutely sure not, that it was a mistake and we will fix it by not continuing to do that. >> The whole thing does not scale with a lot of interfaces or on boxes >> with many changes. The rules file just gets full of garbage over time. > True, but these are corner cases. It's not. It's a real bug. That you and I have only one disk in our box, is no reason for udev not to require to work with 40.000 disks out-of-the-box. We must stop pretending and solving problems which are actually no problems. >> Only one thing seems sure for now, that udev must stop renaming things >> in the kernel namespace. The details for the rest we will need to find >> out. :) > Maybe you can get away with removing features, but I need to support the > ones used by my users so I am strongly opposed to removing this code > until other software will support all current use cases. > As you showed, distributions which do not feel like supporting it can > just disable it. When we get there, it will no longer be part of udev, deleted from the sources. It was a mistake to make a promise we can't deliver. There will be still infrastructure, the mechanics to rename and manage interfaces, but there will be no policy to execute it by default, no rules creator running at hotplug time. People who want *auto* rules creation can add the files themselves, they will not be provided by udev. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
