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

[Ralph Sennhauser <ralph.sennhauser@gmail.com>]

Hi Gregory

On Fri, 26 Aug 2016 10:43:43 +0200
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:

> Hi Ralph,
>  
>  On jeu., août 25 2016, Ralph Sennhauser <ralph.sennhauser@gmail.com>
> wrote:
> 
> > Hi Jason.
> >
> > On Wed, 24 Aug 2016 21:48:36 +0000
> > Jason Cooper <jason@lakedaemon.net> wrote:
> >  
> >> All,
> >> 
> >> On Wed, Aug 24, 2016 at 10:41:02PM +0200, Ralph Sennhauser wrote:  
> >> > On Wed, 24 Aug 2016 20:15:31 +0200
> >> > Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:    
> >> > > On Wed, 24 Aug 2016 19:10:04 +0200, Ralph Sennhauser wrote:
> >> > > 
> >> > > The people who can take this decision are rather the
> >> > > maintainers of the platform itself, or possibly the arm-soc
> >> > > maintainers if you still don't like what the platform
> >> > > maintainers decided.    
> >> > 
> >> > We both have a conflict of interest here, so your offer in an
> >> > other message to let the platform maintainers decide is
> >> > appreciated.    
> >> 
> >> Ok, I'm going to jump in here with the caveats that a) I don't mind
> >> being overruled, and b) I'm not going to participate in a
> >> never-ending thread on this topic.  ;-)  
> >
> > I'm also not interested in a never ending thread. It's moot that
> > udev  
> 
> I am the one who applied this commit.
> 
> First it is really unfortunate this problem was not raised when this
> patch was discussed especially because openwrt was part of the
> discussion:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/411382.html
> 
> Then, the main motivation for merging this patch was to ease the work
> of people doing bring-up of new board using Armada 38x SoCs. When
> doing this we just rely on datasheet and U-Boot and it occurred that
> the way the Soc was designed they put the first GMAC at a higher
> address to the second one. Respecting this order helps low level
> development.
> 
> However for more advanced configuration we expect that more clever
> tools such as udev should be used. (and Lennart confirm that it is
> still working).
> 
> Also note that in the past we considered to being able to modify the
> order of the ethernet device from the device tree by using the
> alias. But the idea was rejected by David Miller (the network
> subsystem maintainer) because this kind of policy should be done at
> userspace level.
> 
> For these reasons I won't revert this commit.
> 


Look at the Gentoo ebuild for Lennarts definition of works. But yes,
obviously it can among other ways be addressed in userspace. For me
this never was a technical discussion but one about politics.

>From your mail I take the following:
1) It's not a case of sneaking in the change and hoping no one notices
before it hits stable.
2) It "broke" those Linksys devices but as you had an offer for testing
I can only assume fair game.
3) You feel comfortable holding out your neck creating a precedent.

Therefore I respect your decision and wont pursue the issue any further.

Thanks
Ralph


> Gregory
> 
> 
> > can't rename to kernel names sanely and we were sold ep34aj17asz98
> > as the replacement. Or that tearing apart the casing to replace the
> > wifi modules with an ethernet one when there are already 5 Gbit
> > ports is not a case I care about.
> >
> > Relying on the order might in theory have flaws but works just fine
> > in practice. Thomas Petazzoni, I, OpenWrt / Lede / etc all do so
> > with success.
> >
> > It's also not a side effect from major changes, so it didn't break
> > by accident but as the subject says deliberately.
> >  
> >> So, I'm just a back-seat co-maintainer for mvebu nowadays, my
> >> opinion should be taken with a grain of salt.
> >> 
> >> From the kernel-side, there is no guarantee of device naming.  The
> >> kernel simply doesn't have sufficient information at boot time.
> >> This is why udev, systemd-udev-ntpd-syslog-kitchensink, and others
> >> were created. To read immutable attributes of a device and apply
> >> consistent naming to them based on configuration files.  That's why
> >> userspace frequently uses uuids to locate partitions, rather
> >> than /dev/sdX[0-9] nodes.
> >> 
> >> The devicetree "ordered by address" rule is, in my opinion, an
> >> arbitrary CDO-rule [1].  It doesn't describe the hardware, or a
> >> relationship between them.  As such, it's just as arbitrary as
> >> probe order.  It just happens to be something we can twiddle.  It
> >> also depends on dtc preserving that order.
> >>   
> >
> > How exceptional is this exception we are talking about? I mean if
> > it's the only place you might want to change it even in 2 years but
> > you can't because of the very same rule which was broken here.
> >  
> >> From the user side, without udev and friends, shit changed from one
> >> kernel to the next.  That's not good.  I can certainly see the
> >> point that it should have been left alone to begin with.  But we
> >> aren't there today.
> >>   
> >
> > I think if we were at 4.6-rcX reverting would be an easy call. I
> > know it's more difficult to make this call now.
> >
> > Ltsi is 4.1, longterm is 4.4, so penetration is probably marginal at
> > best at this time. From my view the damage caused by a revert would
> > be less than the damage that will be caused by the commit if left
> > in but we can't wait much much longer until this changes.
> >  
> >> So what happens if we revert now?  Right or wrong, in a couple of
> >> months, someone else will complain, asking to revert the revert.
> >> And what will our answer be?  "We did it last time, but not this
> >> time." or "Ok, but gosh-darnit, this is the last time."
> >>   
> >
> > If you use the ordering by address as main argument for the revert
> > there will be nothing to argue about.
> >  
> >> To be blunt, I think our best path forward is to just hold our
> >> noses and let it stand as is.  Some will fix their userspace to
> >> adapt, others will carry a patch.  It's more important at this
> >> point to be consistent moving forward.  It's better to hear "Yeah,
> >> it fucking changed once." rather than "I don't know what to
> >> expect, it changes every few releases."
> >> 
> >> thx,
> >> 
> >> Jason.
> >> 
> >> 
> >> [1] CDO: OCD with the letters neatly arranged in alphabetical
> >> order.  
> >
> > Thanks for sharing your thoughts
> >
> > Regards
> > Ralph  
>