devicename part of LEDs under ethernet MAC / PHY

devicename part of LEDs under ethernet MAC / PHY

[Marek Behún]

Hello Pavel, Andrew,

previously we discussed devicename part of LEDs connected under
ethernet MACs and/or ethrenet PHYs.

I would like to finally settle this, but there is one more thing that
may be problematic.

To remind the current proposal, discussed in previous e-mails:

- for LEDs under an ethernet PHY, the devicename part of the LED should
  be "ethphyN", with N an auto-incrementing number for each struct
  phy_device
- for LEDs under an ethernet MAC, it should be similar: "ethmacN"

- the numbers in ethmac and ethphy are unrelated and cannot be related

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

Note that this names are visible to userspace as symlinks
/sys/class/leds directory. If they are unstable, it is not that big an
issue, because mostly these LEDs should be accessed via
/sys/class/net/<interface>/device/leds for eth MAC LEDs and via
/sys/class/net/<interface>/phydev/leds for eth PHY LEDs.

If we wanted to make these names stable, we would need to do something
like
  ethphy-BUS-ID
for example
  ethphy-usb3,2
  ethmac-pci0,19,0
  ethphy-mdio0,1
or
  ethmac-DEVICE_PATH (with '/'s and ':'s replaced with ',' or something)
for example
  ethphy-platform,soc,soc,internal-regs,f10f0000.usb3,usb3,3-0,1:0

The first scheme is nicer but would need some additional code for each
bus.
The second scheme is simpler to implement, but the naming is hideous -
the whole point of devicename part of LEDs was (in my understanding) to
be a nice name, like "mmc0".

Marek

Re: devicename part of LEDs under ethernet MAC / PHY

[Andrew Lunn]

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

> Note that this names are visible to userspace as symlinks
> /sys/class/leds directory. If they are unstable, it is not that big an
> issue, because mostly these LEDs should be accessed via
> /sys/class/net/<interface>/device/leds for eth MAC LEDs and via
> /sys/class/net/<interface>/phydev/leds for eth PHY LEDs.

Yes, this also handles network name space nicely.

> If we wanted to make these names stable, we would need to do something
> like
>   ethphy-BUS-ID
> for example
>   ethphy-usb3,2
>   ethmac-pci0,19,0
>   ethphy-mdio0,1
> or
>   ethmac-DEVICE_PATH (with '/'s and ':'s replaced with ',' or something)
> for example
>   ethphy-platform,soc,soc,internal-regs,f10f0000.usb3,usb3,3-0,1:0

I guess Systemd can be extended to do this, maybe, rename the LEDs
when it renames the interface? This is not really a kernel problem.

     Andrew

Re: devicename part of LEDs under ethernet MAC / PHY

[Marek Behún]

On Fri, 1 Oct 2021 14:29:17 +0200
Andrew Lunn <andrew@lunn.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.

> > Note that this names are visible to userspace as symlinks
> > /sys/class/leds directory. If they are unstable, it is not that big an
> > issue, because mostly these LEDs should be accessed via
> > /sys/class/net/<interface>/device/leds for eth MAC LEDs and via
> > /sys/class/net/<interface>/phydev/leds for eth PHY LEDs.  
> 
> Yes, this also handles network name space nicely.
> 
> > If we wanted to make these names stable, we would need to do something
> > like
> >   ethphy-BUS-ID
> > for example
> >   ethphy-usb3,2
> >   ethmac-pci0,19,0
> >   ethphy-mdio0,1
> > or
> >   ethmac-DEVICE_PATH (with '/'s and ':'s replaced with ',' or something)
> > for example
> >   ethphy-platform,soc,soc,internal-regs,f10f0000.usb3,usb3,3-0,1:0  
> 
> I guess Systemd can be extended to do this, maybe, rename the LEDs
> when it renames the interface? This is not really a kernel problem.

Pavel is against LED classdev renaming.

Marek

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

[Marek Behún]

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@kernel.org> wrote:

> On Fri, 1 Oct 2021 14:29:17 +0200
> Andrew Lunn <andrew@lunn.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.

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

[Greg Kroah-Hartman]

On Sun, Oct 03, 2021 at 10:53:38PM +0200, Marek Behún wrote:
> Hello Greg,
> 
> could you give your opinion on this discussion?

What discussion?  Top posting ruins that :(

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

Stable in what exact way?

Numbering of devices (where a dynamic value is part of a name, like the
"42" in "usb42"), is never guaranteed to be stable, but the non-number
part of the name (like "usb" is in "usb42") is stable, as that is what
you have properly documented in the Documentation/ABI/ files defining
the bus and class devices, right?

The very reason we export all of this information to userspace is so
that userspace can figure it all out in ways it wants to, if it wants
to, and no naming scheme that has to be static and deterministic is
forced into the kernel, where it does NOT belong.

That is 1/2 of the reason why we created the whole "unified
device/driver model" in the kernel in the first place all those years
ago.

Does that help?  I can't figure out what the "problem" is here...

thanks,

greg k-h

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

[Marek Behún]

Hi Greg,

On Mon, 4 Oct 2021 08:37:37 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Sun, Oct 03, 2021 at 10:53:38PM +0200, Marek Behún wrote:
> > Hello Greg,
> > 
> > could you give your opinion on this discussion?  
> 
> What discussion?  Top posting ruins that :(

Sorry, the discussion is here
https://lore.kernel.org/linux-leds/20211001144053.3952474a@thinkpad/T/
But the basic question is below, so you don't need to read the
discussion.

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

Example:
- Board has an ethernet PHYs that is described in DT, and therefore
  has stable sysfs path (derived from DT path), something like
    /sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01

- The PHY has a subnode describing a LED.
  The LED subsystem has a different naming scheme (it uses DT node name
  as a last resort). When everything is okay, the dev_name() of the LED
  will be something like
    ethphy42:green:link

- Now suppose that the PHY driver is unloaded and loaded again. The PHY
  sysfs path is unchanged, but the LED will now be named
    ethphy43:green:link

Is this OK?

> Numbering of devices (where a dynamic value is part of a name, like the
> "42" in "usb42"), is never guaranteed to be stable, but the non-number
> part of the name (like "usb" is in "usb42") is stable, as that is what
> you have properly documented in the Documentation/ABI/ files defining
> the bus and class devices, right?

It does make sense for removable devices like USB. What I am asking
is whether it is also OK for devices that have stable DT nodes.

Marek

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

[Greg Kroah-Hartman]

On Mon, Oct 04, 2021 at 09:04:38AM +0200, Marek Behún wrote:
> Hi Greg,
> 
> On Mon, 4 Oct 2021 08:37:37 +0200
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> 
> > On Sun, Oct 03, 2021 at 10:53:38PM +0200, Marek Behún wrote:
> > > Hello Greg,
> > > 
> > > could you give your opinion on this discussion?  
> > 
> > What discussion?  Top posting ruins that :(
> 
> Sorry, the discussion is here
> https://lore.kernel.org/linux-leds/20211001144053.3952474a@thinkpad/T/
> But the basic question is below, so you don't need to read the
> discussion.
> 
> > > Are device names (as returned by dev_name() function) also part of
> > > sysfs ABI? Should these names be stable across reboots / kernel
> > > upgrades?  
> > 
> > Stable in what exact way?
> 
> Example:
> - Board has an ethernet PHYs that is described in DT, and therefore
>   has stable sysfs path (derived from DT path), something like
>     /sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01

None of the numbers there are "stable", right?

> - The PHY has a subnode describing a LED.
>   The LED subsystem has a different naming scheme (it uses DT node name
>   as a last resort). When everything is okay, the dev_name() of the LED
>   will be something like
>     ethphy42:green:link

Wonderful, but the "42" means nothing.

> - Now suppose that the PHY driver is unloaded and loaded again. The PHY
>   sysfs path is unchanged, but the LED will now be named
>     ethphy43:green:link
> 
> Is this OK?

Yup!

The "link" should point to the device it is associated with, right?  You
need to have some way to refer to the device.

> > Numbering of devices (where a dynamic value is part of a name, like the
> > "42" in "usb42"), is never guaranteed to be stable, but the non-number
> > part of the name (like "usb" is in "usb42") is stable, as that is what
> > you have properly documented in the Documentation/ABI/ files defining
> > the bus and class devices, right?
> 
> It does make sense for removable devices like USB. What I am asking
> is whether it is also OK for devices that have stable DT nodes.

Any device can be "removed" from the system and added back thanks to the
joy of the driver model :)

Also, what prevents your DT from renumbering things in an update to it
in the future?  The kernel doesn't care, and userspace should be able to
handle it.

Again, any numbering scheme is NEVER stable, just because it feels like
it is at the moment for your device, you should NEVER rely on that, but
instead rely on the attributes of the device to determine what it is and
where it is in the device hierarchy (serial number, position location,
partition name, etc.) in order to know what it associated with.

And again, this is 1/2 of the whole reason _why_ we created the unified
driver model in the kernel.  Don't try to go back to the nightmare that
we had in the 2.4 and earlier kernel days please.

thanks,

greg k-h

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

[Marek Behún]

On Mon, 4 Oct 2021 09:10:35 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Mon, Oct 04, 2021 at 09:04:38AM +0200, Marek Behún wrote:
> > Hi Greg,
> > 
> > On Mon, 4 Oct 2021 08:37:37 +0200
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >   
> > > On Sun, Oct 03, 2021 at 10:53:38PM +0200, Marek Behún wrote:  
> > > > Hello Greg,
> > > > 
> > > > could you give your opinion on this discussion?    
> > > 
> > > What discussion?  Top posting ruins that :(  
> > 
> > Sorry, the discussion is here
> > https://lore.kernel.org/linux-leds/20211001144053.3952474a@thinkpad/T/
> > But the basic question is below, so you don't need to read the
> > discussion.
> >   
> > > > Are device names (as returned by dev_name() function) also part of
> > > > sysfs ABI? Should these names be stable across reboots / kernel
> > > > upgrades?    
> > > 
> > > Stable in what exact way?  
> > 
> > Example:
> > - Board has an ethernet PHYs that is described in DT, and therefore
> >   has stable sysfs path (derived from DT path), something like
> >     /sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01  
> 
> None of the numbers there are "stable", right?
> 
> > - The PHY has a subnode describing a LED.
> >   The LED subsystem has a different naming scheme (it uses DT node name
> >   as a last resort). When everything is okay, the dev_name() of the LED
> >   will be something like
> >     ethphy42:green:link  
> 
> Wonderful, but the "42" means nothing.
> 
> > - Now suppose that the PHY driver is unloaded and loaded again. The PHY
> >   sysfs path is unchanged, but the LED will now be named
> >     ethphy43:green:link
> > 
> > Is this OK?  
> 
> Yup!
> 
> The "link" should point to the device it is associated with, right?  You
> need to have some way to refer to the device.
> 
> > > Numbering of devices (where a dynamic value is part of a name, like the
> > > "42" in "usb42"), is never guaranteed to be stable, but the non-number
> > > part of the name (like "usb" is in "usb42") is stable, as that is what
> > > you have properly documented in the Documentation/ABI/ files defining
> > > the bus and class devices, right?  
> > 
> > It does make sense for removable devices like USB. What I am asking
> > is whether it is also OK for devices that have stable DT nodes.  
> 
> Any device can be "removed" from the system and added back thanks to the
> joy of the driver model :)
> 
> Also, what prevents your DT from renumbering things in an update to it
> in the future?  The kernel doesn't care, and userspace should be able to
> handle it.
> 
> Again, any numbering scheme is NEVER stable, just because it feels like
> it is at the moment for your device, you should NEVER rely on that, but
> instead rely on the attributes of the device to determine what it is and
> where it is in the device hierarchy (serial number, position location,
> partition name, etc.) in order to know what it associated with.
> 
> And again, this is 1/2 of the whole reason _why_ we created the unified
> driver model in the kernel.  Don't try to go back to the nightmare that
> we had in the 2.4 and earlier kernel days please.

OK, thanks Greg. This simplifies things. I shall send another version
of LEDs under ethernet PHYs soon :)

Marek

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

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]

Hi!

> > > > Are device names (as returned by dev_name() function) also part of
> > > > sysfs ABI? Should these names be stable across reboots / kernel
> > > > upgrades?  
> > > 
> > > Stable in what exact way?
> > 
> > Example:
> > - Board has an ethernet PHYs that is described in DT, and therefore
> >   has stable sysfs path (derived from DT path), something like
> >     /sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01
> 
> None of the numbers there are "stable", right?

At least f1072004 part is stable (and probably whole path). DT has
advantages here, and we should provide stable paths when we can.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Greg Kroah-Hartman]

On Mon, Oct 04, 2021 at 09:38:41AM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > Are device names (as returned by dev_name() function) also part of
> > > > > sysfs ABI? Should these names be stable across reboots / kernel
> > > > > upgrades?  
> > > > 
> > > > Stable in what exact way?
> > > 
> > > Example:
> > > - Board has an ethernet PHYs that is described in DT, and therefore
> > >   has stable sysfs path (derived from DT path), something like
> > >     /sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01
> > 
> > None of the numbers there are "stable", right?
> 
> At least f1072004 part is stable (and probably whole path). DT has
> advantages here, and we should provide stable paths when we can.

The kernel should enumerate the devices as best that it can, but it
never has the requirement of always enumerating them in the same way
each time as many busses are not deterministic.

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

[Andrew Lunn]

On Mon, Oct 04, 2021 at 10:30:25AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Oct 04, 2021 at 09:38:41AM +0200, Pavel Machek wrote:
> > Hi!
> > 
> > > > > > Are device names (as returned by dev_name() function) also part of
> > > > > > sysfs ABI? Should these names be stable across reboots / kernel
> > > > > > upgrades?  
> > > > > 
> > > > > Stable in what exact way?
> > > > 
> > > > Example:
> > > > - Board has an ethernet PHYs that is described in DT, and therefore
> > > >   has stable sysfs path (derived from DT path), something like
> > > >     /sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01
> > > 
> > > None of the numbers there are "stable", right?
> > 
> > At least f1072004 part is stable (and probably whole path). DT has
> > advantages here, and we should provide stable paths when we can.
> 
> The kernel should enumerate the devices as best that it can, but it
> never has the requirement of always enumerating them in the same way
> each time as many busses are not deterministic.

And for this particular SoC, it is possible to map the memory mapped
IO at a different address range. It is the bootloader which determines
this. There are some Marvell uboot's which use 0xd0000000, not
0xf0000000.  So strictly speaking, f1072004 is not stable, it is not
hard wired in the silicon.

   Andrew