lkml.org 
[lkml]   [2016]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Regression?] Commit cb4f71c429 deliberately changes order of network interfaces
    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. ;-)

    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.

    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.

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

    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.

    \
     
     \ /
      Last update: 2016-09-17 09:57    [W:2.338 / U:0.200 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site