On Fri, May 27, 2011 at 03:26, Marco d'Itri <md@xxxxxxxx> wrote: > On May 26, Kay Sievers <kay.sievers@xxxxxxxx> wrote: > >> 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. > My experience is clearly different, so looks like our respective user > bases have different needs. It almost always solves the problem of > interface names not changing after a reboot and breaking everything. Sure, it works on more boxes than it fails. But the thing is that it is just not needed for the majority of boxes. So the few ones where the auto-setup is helpful don't justify all the problems this solution brings. We have to admit we had an idea, we tried to solve it, and it does not work out, or is not needed. So we decided to stop doing it. It's just not worth the trouble. >> 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. > Again, it has worked well enough for my users for the last 5 years so it > cannot be so much broken. Nope, it doesn't work. We run all the renaming during bootup while we still load kernel modules. The interface creation from inside the kernel races against our renaming/name swapping. Names we just freed to take them with a rename get re-used for newly created interfaces in the kernel. These are real bugs with bug reports. We can never fix that properly. It's a game we can only lose. >> 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. > While it may not cover all cases it still beats all the existing > alternatives. I will be ready to reconsider my position when new > software will appear to handle the currently supported cases. The only sensible option is to provide system-management tools to specify stable custom names for interfaces based on whatever match that fits. We should stop trying to solve problems which don't really exist. Today's stuff handles other names than ethX just fine, and the majority of boxes handles changing names at reboot just fine. >> 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. > I can continue maintaining the scripts in my tree as long as it will be > needed, but removing support for renaming interfaces in the same > namespace (which, again, works fine for all my users) will be seriously > inconvenient. Sure, that's up to the distro, what to do. It's just that upstream will not continue to provide things that can't be fixed properly. Just look at the VMware example: We excluded it because the auto-rules crated trouble for VMware images, now people think they want it. It just does not make sense to try to be smart here. We can't solve these issues automatically. It sounds good, but it's bad in reality. People who need persistent names, need it for a reason, they have a custom matching network config. So they need to setup the interface config they match against too. Udev will get out of their way, and only do what it it told to do instead of trying to fix non-existing problem, and create a ton of new ones that way. 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
