Hello Steve, thanks for your thoughts!
Steve Langasek [2016-04-06 14:47 -0700]: > 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). Right, so this assumes having a writable /etc (which is another -, and we spend some significant efforts on getting r/o images), but you can have a first-boot config item indeed. You can also ship some custom config to switch to a different policy. I. e. the point is not that having this default policy makes it impossible to use pre-configured images, just that it takes some extra effort. > *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? This would combine the unpredictable (because timing-dependent) naming with the need for having to have write access to /etc. So, it's certainly technically feasible to bring back the generator for this, but I don't see much advantage in doing that other than avoiding the long names. > (With appropriate fixes to the choice of names to eliminate the > previous race conditions) Yeah, that part is not a problem, they could be called "enusbN". > 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'm afraid I don't understand the "if" here. With persistent-net-generator we of course do need to write the dynamically created .rules, and that'd be a network device naming. But I thought we were heading into the "read-only"/"reproducible" direction, so this kind of random network naming doesn't really help there. > I think you also left off "long and ugly names" as a - for this option. Right (I mentioned it above, but not in the list), thanks. > 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. IMHO that's still not significantly smaller enough to be able to memorize it, so it's copy&paste in either case. But then you have a number/name which doesn't match anything the user can see in NM config or "ip a", while the MAC address is often even printed on a device label. Plus, it'd be a downstream specific patch and introduce yet another type of policy, so all around I think it'd be too high cost/low benefit. > 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. I think we'd get some really angry messages from people who have to type it on a keyboard which doesn't happen to have keys for ¶, þ, non-breaking space or form-feed ☺ (in other words, pretty much everyone in the world) > 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. Right, definitively for IoT. For the more "classic" server world USB network interfaces are fairly rare, and for cloud it's of course not an issue at all. > 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. Right, that's the core of the question -- do we have more scenarios which work better with location or with device identity. So for this particular scenario it's a guarantee that device names by identity (i. e. MAC based) differ between different devices -- while it's merely likely that names differ with location-based naming, but significantly likely to be preferrable. But as I said this is the point where there's no objective data any more, and also why this keeps coming up.. > > > * Keep the kernel name (like eth0) for USB devices > > * 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. > > 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. Correct, as per the "*" point above. I brought it up mostly because the common case is to only have (at most) one USB device, and saying "if you need multiple devices with known names you have to set them up yourself according to what *you* need" is at least consistent and plausible (but of course not necessarily better than using some ifname schema). > 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. Yeah, I agree. As you always have the option to name things yourself, the location-based names would be a better default. I just wanted to be complete in showing and comparing all the options that we have. > And since this option can't be directly coupled with persistent-net.rules > (because kernel names vs. races), FTR, the kernel name racing is only if you rename them to ethN; so if we would bring back the persistent-net-generator for enusbN or usbN or so, there would be no race. > 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. If 70-persistent-net.rules (or any other custom rules exist), this will always win anyway, and our default policy doesn't matter. But using 70-persistent-net.rules would get us back to a state of un-predictability, you merely have stability (plus the added necessity to keep having to write /etc/udev/rules.d/). So I actually feel this is the worst option. But you are right in the sense that this should be a fourth option in the list. Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: PGP signature
-- snappy-devel mailing list snappy-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel
