public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Cooper <jason@lakedaemon.net>
To: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Gregory CLEMENT <gregory.clement@free-electrons.com>,
	Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Subject: Re: [Regression?] Commit cb4f71c429 deliberately changes order of network interfaces
Date: Wed, 24 Aug 2016 21:48:36 +0000	[thread overview]
Message-ID: <20160824214836.GC10637@io.lakedaemon.net> (raw)
In-Reply-To: <20160824224102.685a566a@gmail.com>

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.

  reply	other threads:[~2016-08-24 21:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-21 13:11 [Regression?] Commit cb4f71c429 deliberately changes order of network interfaces Ralph Sennhauser
2016-08-24 14:50 ` Thomas Petazzoni
2016-08-24 16:19   ` Lennart Sorensen
2016-08-24 16:43     ` Thomas Petazzoni
2016-08-24 17:10       ` Lennart Sorensen
2016-08-24 18:38         ` Lennart Sorensen
2016-08-24 17:10   ` Ralph Sennhauser
2016-08-24 18:07     ` Lennart Sorensen
2016-08-24 18:14       ` Thomas Petazzoni
2016-08-24 18:27         ` Lennart Sorensen
2016-08-24 19:52           ` Thomas Petazzoni
2016-08-24 20:51             ` Lennart Sorensen
2016-08-24 18:15     ` Thomas Petazzoni
2016-08-24 20:41       ` Ralph Sennhauser
2016-08-24 21:48         ` Jason Cooper [this message]
2016-08-25  7:38           ` Ralph Sennhauser
2016-08-25 19:40             ` Lennart Sorensen
2016-08-26  8:43             ` Gregory CLEMENT
2016-08-26 10:39               ` Ralph Sennhauser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160824214836.GC10637@io.lakedaemon.net \
    --to=jason@lakedaemon.net \
    --cc=gregory.clement@free-electrons.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lsorense@csclub.uwaterloo.ca \
    --cc=ralph.sennhauser@gmail.com \
    --cc=thomas.petazzoni@free-electrons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox