Netdev List
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: "Michal Suchánek" <msuchanek@suse.de>
Cc: "Tim Harvey" <tharvey@gateworks.com>,
	"Pali Rohár" <pali@kernel.org>,
	"Sean Anderson" <sean.anderson@seco.com>,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	netdev <netdev@vger.kernel.org>, u-boot <u-boot@lists.denx.de>,
	"Device Tree Mailing List" <devicetree@vger.kernel.org>
Subject: Re: ethernet<n> dt aliases implications in U-Boot and Linux
Date: Wed, 10 Aug 2022 17:17:56 +0200	[thread overview]
Message-ID: <YvPMJLSuG3CBC//n@lunn.ch> (raw)
In-Reply-To: <20220810071603.GR17705@kitsune.suse.cz>

> > I guess you are new to the netdev list :-)
> > 
> > This is one of those FAQ sort of things, discussed every
> > year. Anything like this is always NACKed. I don't see why this time
> > should be any different.
> > 
> > DSA is somewhat special because it is very old. It comes from before
> > the times of DT. Its DT binding was proposed relatively earl in DT
> > times, and would be rejected in modern days. But the rules of ABI mean
> > the label property will be valid forever. But i very much doubt it
> > will spread to interfaces in general.
> 
> And if this is a FAQ maybe you can point to a summary (perhaps in
> previous mail discusssion) that explains how to provide stable interface
> names for Ethernet devices on a DT based platform?

As far so the kernel is concerned, interface names are unstable. They
have never been truly stable, but they have got more unstable in the
past decade with multiple busses being probed in parallel, which did
not happen before so much.

> On x86 there is a name derived from the device location in the bus
> topology

This is nothing to do with x86. That is userspace, e.g. systemd,
renaming the interfaces. This applies for any architecture for which
systemd runs on.

> which may be somewhat stable but it is not clear that it
> cannot change, and there is an optional BIOS provided table that can
> asssign meaningful names to the interfaces.

I doubt the kernel is looking at ACPI tables. It is user space which
does that.

The kernel provides udev with a bunch of information about the
interface, its bus location, MAC address, etc. Userspace can then
decide what it wants to call it, and what its alternative names are,
etc.

Also, this is not just a network interface name problem. Any device
with a number/letter in it is unstable. I2C bus devices: i2c0,
i2c1... SPI bus deviceS: spi0, spi1..., Block devices, sda, sdb, sdc,
TPM device, tpm0, tpm1. Nothing is stable in the kernel.

       Andrew

  reply	other threads:[~2022-08-10 15:18 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-08 19:18 ethernet<n> dt aliases implications in U-Boot and Linux Tim Harvey
2022-08-08 19:57 ` Sean Anderson
2022-08-08 21:09   ` Michal Suchánek
2022-08-08 21:38     ` Stephen Hemminger
2022-08-08 21:45       ` Michal Suchánek
2022-08-09 20:48         ` Sean Anderson
2022-08-09 21:31           ` Pali Rohár
2022-08-09 21:36             ` Sean Anderson
2022-08-09 21:42               ` Pali Rohár
2022-08-09 22:41                 ` Sean Anderson
2022-08-09 22:42                   ` Tim Harvey
2022-08-09 22:45                   ` Pali Rohár
2022-08-09 23:17                     ` Tim Harvey
2022-08-10  1:11                       ` Andrew Lunn
2022-08-10  7:16                         ` Michal Suchánek
2022-08-10 15:17                           ` Andrew Lunn [this message]
2022-08-10 15:35                             ` Michal Suchánek
2022-08-11 19:43                               ` Sean Anderson
2022-08-20  9:16                     ` Pali Rohár
2022-08-20 13:02                       ` Sean Anderson
2022-08-09 21:39             ` Tim Harvey
2022-08-09 21:45               ` Pali Rohár
2022-08-09 21:58               ` Stephen Hemminger
2022-08-10  9:56               ` Francesco Dolcini
2022-08-23 19:21               ` Rob Herring
2022-08-09 21:35           ` Tim Harvey
2022-08-09 21:41             ` Sean Anderson
2022-08-08 21:18   ` Tim Harvey
2022-08-08 21:18   ` Florian Fainelli
2022-08-08 21:28     ` Tim Harvey
2022-08-08 21:34       ` Florian Fainelli
2022-08-08 21:40         ` Tim Harvey

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=YvPMJLSuG3CBC//n@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=msuchanek@suse.de \
    --cc=netdev@vger.kernel.org \
    --cc=pali@kernel.org \
    --cc=sean.anderson@seco.com \
    --cc=stephen@networkplumber.org \
    --cc=tharvey@gateworks.com \
    --cc=u-boot@lists.denx.de \
    /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