Re: [Regression?] Commit cb4f71c429 deliberately changes order of network interfaces

[Thomas Petazzoni]

Hello,

On Wed, 24 Aug 2016 12:19:33 -0400, Lennart Sorensen wrote:

> > So having things match the documentation numbering was in our opinion
> > the least confusing thing moving forward. We should have done it
> > earlier, but we thought that the rule "order by register address" was a
> > very strong rule.
> > 
> > At this point, reverting the patch is I believe cause more harm than
> > good. It's going to re-confuse again people.  
> 
> Well wouldn't it only affect the tiny proportian that have moved to a >4.4
> kernel?  Looking at LEDE, openWrt, etc, it seems very few have so far.

Well, just like the for the documentation aspect, you're seeing this
from the OpenWRT/LEDE angle only. Other people are using plenty of
other things.

We knew it would potentially cause some breakage, so it was a
trade-off. I still believe the new arrangement is better, and you've so
far been the only person reporting an issue with this (compared to
numerous people being confused by the original ordering problem).

> > Regarding the fact that the "wrong numbering if actually documented" is
> > a fairly specious argument. The OpenWRT Wiki has never been an official
> > documentation of any sort. I see it as a much more important aspect
> > that the numbering of the Ethernet interfaces matches the user manual
> > Marvell provides with its development and evaluation boards. The
> > OpenWRT Wiki can certainly be fixed accordingly.  
> 
> That could be a good argument.
> 
> Of course this would not be the first linux release to change network
> device ordering.  It has happened many times before.
> 
> Unfortunately I don't see the eth ports on the marvell in udev, so I
> don't know if udev could even help fix the names based on the address
> of the port.

This is more problematic, and something to be investigated. I don't
immediately see why the Marvell network interfaces would not be visible
by udev, but I haven't tested.

> On any system I have been part of making in the past, I always added an
> ifname attribute to the dtb and made the driver use that.  This problem
> is just too silly to put up with.  There needs to be some sane way to
> control the names of the interfaces.

The solution of adding an alias in the DT, and using that to name
network interfaces has already been proposed multiple times, but has
been rejected by the networking maintainer, who suggests to use
userspace tools (udev or something else) to rename network interfaces.
See for example https://patchwork.kernel.org/patch/4122441/, which was
proposed by my colleague Boris Brezillon.

You can always try to propose again a solution, but I doubt it will be
accepted.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com