Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1470598 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Regression?] Commit cb4f71c429 deliberately changes order of network interfaces Gregory CLEMENT <gregory.clement@free-electrons.com> - 2016-08-26 10:50 +0200
    Re: [Regression?] Commit cb4f71c429 deliberately changes order of  network interfaces Ralph Sennhauser <ralph.sennhauser@gmail.com> - 2016-08-26 12:40 +0200

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

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.

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

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[toc] | [next] | [standalone]

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

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  
> 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web