On Wed, 2018-10-24 at 08:22 +0200, Michal Suchánek wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > On Tue, 23 Oct 2018 11:20:36 -0700 > Florian Fainelli <f.faine...@gmail.com> wrote: > > > On 10/23/18 11:02 AM, Joakim Tjernlund wrote: > > > On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote: > > > I also noted that using status = "disabled" didn't work either to > > > create a fix name scheme. Even worse, all the eth I/F after gets > > > renumbered. It seems to me there is value in having stability in > > > eth I/F naming at boot. Then userspace(udev) can rename if need be. > > > > > > Sure would like to known more about why this feature is not wanted ? > > > > > > I found > > > https://patchwork.kernel.org/patch/4122441/ > > > You quote policy as reason but surely it must be better to > > > have something stable, connected to the hardware name, than > > > semirandom naming? > > > > If the Device Tree nodes are ordered by ascending base register > > address, my understanding is that you get the same order as far as > > platform_device creation goes, this may not be true in the future if > > Rob decides to randomize that, but AFAICT this is still true. This > > may not work well with status = disabled properties being inserted > > here and there, but we have used that here and it has worked for as > > far as I can remember doing it. > > So this is unstable in several respects. First is changing the > enabled/disabled status in the deivecetrees provided by the kernel. > > Second is if you have hardware hotplug mechanism either by firmware or > by loading device overlays. > > Third is the case when the devicetree is not built as part of the > kernel but is instead provided by firmware that initializes the > low-level hardware details. Then the ordering by address is not > guaranteed nor is that the same address will be used to access the same > interface every time. There might be multiple ways to configure the > hardware depending on firmware configuration and/or version. > > > > Second, you might want to name network devices ethX, but what if I > > want to name them ethernetX or fooX or barX? Should we be accepting a > > mechanism in the kernel that would allow someone to name the > > interfaces the way they want straight from a name being provided in > > Device Tree?
Just to be clear, I am saying that we don't need to control the full name of the Ethernet device, just the numerical id so one can tie eth0 to a fixed physical device. > > Clearly if there is text Ethernet1 printed above the Ethernet port we > should provide a mechanism to name the port Ethernet1 by default. > > > Aliases are fine for providing relative stability within the Device > > Tree itself and boot programs that might need to modify the Device > > Tree (e.g: inserting MAC addresses) such that you don't have to > > encode logic to search for nodes by compatible strings etc. but > > outside of that use case, it seems to me that you can resolve every > > naming decision in user-space. > > However, this is pushing platform-specific knowledge to userspace. The > way the Ethernet interface is attached and hence the device properties > usable for identifying the device uniquely are platform-specific. > > On the other hand, aliases are universal when provided. If they are > good enough to assign a MAC address they are good enough to provide a > stable default name. > > I think this is indeed forcing the userspace to reinvent several wheels > for no good reason. > > What is the problem with adding the aliases? Well put above, thanks. Jocke
