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

[lsorense@csclub.uwaterloo.ca (Lennart Sorensen)]

On Wed, Aug 24, 2016 at 06:43:34PM +0200, Thomas Petazzoni wrote:
> 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).

I didn't report it.  I just commented.  I will be affected when LEDE
does move their kernel past 4.4 I suppose, but I imagine something will
be done to deal with it.

I have run into issues with things being reordered on other systems
though, and it sure is annoying, especially when the new behaviour
removes the ability to control the order that was previously there
(that is not what is happening here of course).

> 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.

Well certainly doing udevtrigger -n -v I see no ethernet devices (but
lots of other things).  Looking in sysfs it is possible to dereive which
ethX belongs to which port based on the directory names, but that's
probably not the most convinient manner to deal with it.

> 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.

Sure, although it seems many embedded systems would rather avoid udev
(even more so after systemd seems to have taken it over), and in this
case I get the impression so far that udev may not even be able to help
on this system.  (although maybe I just did it wrong).

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

Yeah me too, hence why I can't be bothered to try.  I have accepted
there are some things the maintainers won't fix so I have a few patches 
I maintain myself and can keep doing so.  They are tiny after all.

-- 
Len Sorensen