Bjørn Mork [2015-05-08 16:13 +0200]: > PCI buses can be and are hotplugged, similar to network devices.
Yes, that's certainly a valid point. It's not unanimously clear how you define the "identity" of an interface, whether it's more like "by location" or "by MAC address". There are pros and cons for either POV. Karsten Merker [2015-05-08 18:31 +0200]: > while this probably works resonably well for (semi-)fixed devices > like onboard-NICs and PCI/PCIe cards, it results in a completely > unsuitable behaviour with pluggable devices such as USB network > adapters. TBH, hotpluggable USB network adapters which change all the time sound like a corner case in a server world where you have hand-written config files referring to interface names. They are of course common on the client side, but there stable interface names don't matter at all. But see below. peter green [2015-05-09 8:49 +0100]: > The "path based names" use the PCI bus number as their "root". PCI bus > numbers are dynamically allocated as the bios enumerates the busses. PCI bus and slot numbers are stable across reboots, unless of course you physically change the cards (what Bjørn raised above). So, there's obviously two schools of thoughts here. Some people think in terms of MAC addresses, which breaks if you replace a broken or outdated card with a new one. Some people think in terms of location, like "the left port goes to the internet, the right port to the intranet", and there is absolutely nothing wrong with that either; in that scenario you can replace a network card, but keep the cables etc, and everything will still work. I don't want to get down into philosophical questions whether rearranging the hardware in your server should or shouldn't be considered an identical configuration still, as that's just bikeshedding and we'll never find 100% consensus there. Neither MAC or location based stable names are flawless; the above show pitfalls of location based ones, the whole cloud story (or replacing faulty hardware) shows that MAC addresses are totally unsuitable in common situations. But what I do want to get rid of is the current 70-persistent-net-names.rules which have the inherent race condition and have no configurability at all; and it provides no stable interface names for any virtualized environment. With ifnames you can always choose your own policy (see man systemd.link), and e. g. say "NamePolicy=onboard mac" if you so prefer. We can even discuss preferring "mac" over "slot" by default (although I personally think that would be a worse default). One could even default to "mac" for USB based hardware and the default (kernel database onboard slot path) for others [1]. Martin [1] I don't have USB-ethernet devices myself; if you have one, please get in touch with me, I'd like to investigate how they look like in udev, and what "udevadm test /sys/class/net/<iface> |grep NAME" says about these. -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150509092614.gb3...@piware.de