Hi Martin, $.02:
On Wed, Apr 06, 2016 at 12:56:44PM +0200, Martin Pitt wrote: > However, as there were some complaints [2][3] about location-based > names not being appropriate for USB devices, we currently use the MAC > address for those. I. e. they are named like "enx123456AABBCC". > After having seen this in practice for a while, I wonder whether that > was actually the right decision. There's the stylistic issue of these > names being very long, but if you configure ifupdown or your firewall > etc. with those, you only need to copy&paste it exactly once. The more > important question is whether treating them as "device identity" as > oppposed to "where do I connect it" is actually the right default. > These are the options with pros (+) and cons (-): > * MAC based (status quo): Emphasize the identity of the device that > you connect > + Works well on PCs/laptops where you want to connect your phone or > USB 3G stick on an arbitrary USB slot. > - With boards like the RasPi you usually think in terms of > location: The left port is for the external USB ethernet card, > the right port for something else. > - You can't just take a pre-configured image and install it on a > bunch of RasPis, as the configuration depends on the particular > USB ethernet dongle that you plug in, so the names will be > different on every deployed device, you can't keep a r/o > image, and you need to adjust the configuration everywhere. Well, you can use such a preconfigured image; but we achieve this by having first-boot code that takes the information about the network interface mappings and writes it to the writable config space of the device (via /etc/network/interfaces.d). *If* we rule out using either location-based or kernel default names for USB devices, would it make sense to go back to /etc/udev/rules.d/70-persistent-net.rules for this case? (With appropriate fixes to the choice of names to eliminate the previous race conditions) If you have to write some per-device config data about the network card, why not have that be a network device name mapping, so that everything higher up the stack can use it consistently - and give us pretty names in the process? I think you also left off "long and ugly names" as a - for this option. On that point, it occurs to me that we aren't using the MAC address in the interface name because we want to expose the MAC address to the user, but only because we want something predictable and collision-free. Therefore there's no actual reason that the MAC address has to be represented as a long hex string. What about a base64 representation? That would give you 8 characters instead of 12 to represent the MAC address. Or, how good is the support for unicode in interface names? A "base256" encoding using extended Latin characters as its charset would only require 6 characters to represent a MAC address. But OK, that's unfriendly to anyone who doesn't have access to those characters on their keyboard for input; and very unfriendly to anyone using a non-UTF8 CJK locale. > * Location based (upstream default): Emphasize the location of the > device that you connect; this has opposite pros and cons: > + Works well on embedded boards where you more likely think in > terms of location and USB port numbers than "did I use this or > that USB ethernet adapter" > + Is much more suitable for pre-configuring an image and deploying > it to lots of devices. > - Breaks on laptops/desktops with lots of USB ports when you tend > to plug in your phone/USB dongle in different ports every time. > Although there it probably doesn't matter as NetworkManager > does not care about device names and connections are set up > dynamically -- it's relatively unlikely that you use ifupdown or > custom name-based firewall rules for hotpluggable USB network > interfaces. If NM can properly track this, then I don't think there's much of an argument that this is unsuitable on the desktop. On non-desktop systems (server and IoT), it's more of a problem for the interface name to change, for all the usual reasons. These devices also tend to have their network interfaces provisioned much more statically, whether or not they're USB. However, while that may be true for any individual device, it's less true that *all* devices are going to have their USB NIC configured with the same topology. Even within a single class of device, people may individually hook USB NICs up to different ports; but across *all* devices that we would expect to work out of the box with a common rootfs, it's absolutely certain that there's no single location-based interface name that will be correct for all systems. So it doesn't appear that this option gets us away from the requirement for storing state at first boot. > * Keep the kernel name (like eth0) for USB devices > - Does not provide any stable names if you have multiple USB > devices at the same time (however, this doesn't appear to be a > common case) > * I. e. this requires you to manually configure names IF you need > to refer to the names in config files (ifupdown, firewall) AND > you need multiple USB network devices simultaneously. > + If you only ever use at most one USB device (the common case), > the name "eth0" is reasonably predictable, and pre-configured > systems (like Raspis) with hardcoded "eth0" have a reasonably > high chance of working out of the box. > - There are no firm guarantees about the kernel actually naming the > device "eth0" in all cases. AIUI this option means users with multiple USB interfaces may see their device names flip back and forth across boots, due to the lack of stable enumeration of USB. That seems like it incorporates the downsides of both of the other options. We're definitely not solving the need for on-disk state to make interface names persistent in the general case, so I don't think it's any more elegant than what we have currently *except* that the name is less ugly. And since this option can't be directly coupled with persistent-net.rules (because kernel names vs. races), I think if we *don't* want either location or MAC based rules, we should instead go with some other simple first-come-first-serve naming scheme that doesn't collide with kernel names and which *optionally* uses persistent-net.rules if writable. HTH, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel