Hi Gregory On Fri, 26 Aug 2016 10:43:43 +0200 Gregory CLEMENT <gregory.clem...@free-electrons.com> wrote:
> Hi Ralph, > > On jeu., août 25 2016, Ralph Sennhauser <ralph.sennhau...@gmail.com> > wrote: > > > Hi Jason. > > > > On Wed, 24 Aug 2016 21:48:36 +0000 > > Jason Cooper <ja...@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.petazz...@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 >