Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sun, 3 Oct 2021 22:53:38 +0200
From:   Marek =?UTF-8?B?QmVow7pu?= <kabel@kernel.org>
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     Andrew Lunn <andrew@lunn.ch>, Pavel Machek <pavel@ucw.cz>,
        "linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
        netdev@vger.kernel.org,
        Jacek Anaszewski <jacek.anaszewski@gmail.com>,
        linux-kernel@vger.kernel.org
Subject: are device names part of sysfs ABI? (was Re: devicename part of
 LEDs under ethernet MAC / PHY)
Message-ID: <20211003225338.76092ec3@thinkpad>
In-Reply-To: <20211001144053.3952474a@thinkpad>
References: <20211001133057.5287f150@thinkpad>
        <YVb/HSLqcOM6drr1@lunn.ch>
        <20211001144053.3952474a@thinkpad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hello Greg,

could you give your opinion on this discussion?

Are device names (as returned by dev_name() function) also part of
sysfs ABI? Should these names be stable across reboots / kernel
upgrades?

Marek

On Fri, 1 Oct 2021 14:40:53 +0200
Marek Beh=C3=BAn <kabel@kernel.org> wrote:

> On Fri, 1 Oct 2021 14:29:17 +0200
> Andrew Lunn <andrew@lunn.ch> wrote:
>=20
> > > - Andrew proposed that the numbering should start at non-zero number,
> > >   for example at 42, to prevent people from thinking that the numbers
> > >   are related to numbers in network interface names (ethN).
> > >   A system with interfaces
> > >     eth0
> > >     eth1
> > >   and LEDs
> > >     ethphy0:green:link
> > >     ethphy1:green:link
> > >   may make user think that the ethphy0 LED does correspond to eth0
> > >   interface, which is not necessarily true.
> > >   Instead if LEDs are
> > >     ethphy42:green:link
> > >     ethphy43:green:link=20
> > >   the probability of confusing the user into relating them to network
> > >   interfaces by these numbers is lower.
> > >=20
> > > Anyway, the issue with these naming is that it is not stable. Upgradi=
ng
> > > the kernel, enabling drivers and so on can change these names between
> > > reboots.   =20
> >=20
> > Sure, eth0 can become eth1, eth1 can become eth0. That is why we have
> > udev rules, systemd interface names etc. Interface names have never
> > been guaranteed to be stable. Also, you can have multiple interfaces
> > named eth0, so long as they are in different network name spaces.
> >  =20
> > > Also for LEDs on USB ethernet adapters, removing the USB and
> > > plugging it again would change the name, although the device path does
> > > not change if the adapter is re-plugged into the same port.
> > >=20
> > > To finally settle this then, I would like to ask your opinion on
> > > whether this naming of LEDs should be stable.   =20
> >=20
> > No. They should be unstable like everything else. =20
>=20
> LED classdev names are something different.
> For etherent interfaces, the interface name is different from name of
> the underlying struct device. But LED classdev names are also
> corresponding struct device names, and thus part of sysfs ABI, which,
> as far as I understand, should be stable.