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/
slangasek@ubuntu.com vorlon@debian.org
