linux-kernel - are device names part of sysfs ABI? (was Re: devicename part of LEDs under ethernet MAC / PHY)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 3 Oct 2021 22:53:38 +0200
From:   Marek Behún <kabel@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Andrew Lunn <andrew@...n.ch>, Pavel Machek <pavel@....cz>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
        netdev@...r.kernel.org,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        linux-kernel@...r.kernel.org
Subject: are device names part of sysfs ABI? (was Re: devicename part of
 LEDs under ethernet MAC / PHY)

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ún <kabel@...nel.org> wrote:

> On Fri, 1 Oct 2021 14:29:17 +0200
> Andrew Lunn <andrew@...n.ch> wrote:
> 
> > > - 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 
> > >   the probability of confusing the user into relating them to network
> > >   interfaces by these numbers is lower.
> > > 
> > > Anyway, the issue with these naming is that it is not stable. Upgrading
> > > the kernel, enabling drivers and so on can change these names between
> > > reboots.    
> > 
> > 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.
> >   
> > > 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.
> > > 
> > > To finally settle this then, I would like to ask your opinion on
> > > whether this naming of LEDs should be stable.    
> > 
> > No. They should be unstable like everything else.  
> 
> 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.