lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 24 Aug 2016 12:19:33 -0400
From:   lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:     Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Cc:     Ralph Sennhauser <ralph.sennhauser@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Gregory CLEMENT <gregory.clement@...e-electrons.com>
Subject: Re: [Regression?] Commit cb4f71c429 deliberately changes order of
 network interfaces

On Wed, Aug 24, 2016 at 04:50:11PM +0200, Thomas Petazzoni wrote:
> We had many many users getting confused by the fact that the order of
> the network interfaces was inverted compared to:
> 
>  * The board documentations
>  * The U-Boot numbering
>  * And to a lesser extent, the vendor kernel
> 
> 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.

I don't think that's a good argument.

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

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.

-- 
Len Sorensen

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ