Hi Heiner (and Pavel and Florian and others),
On Mon, 26 Jul 2021 22:59:05 +0200
Heiner Kallweit <hkallweit1@xxxxxxxxx> wrote:
> The issue with this is mentioned by Andrew a few lines before. At least in
> network subsystem the kernel identifiers can be changed from userspace.
> Typical example is the interface renaming from eth0 to e.g. enp1s0.
> Then a LED eth0-led1 would have to be automagically renamed to enp1s0-led1.
> An option for this could be to make a LED renaming function subscribe to
> interface name change notifications. But this looks to me to like using a
> quite big hammer for a rather small nail.
We are not going to be renaming LEDs on inteface rename, that can
introduce a set of problems on it's own.
Yes, if network interface renaming were not possible, the best option
would be to use interface names. It is not possible.
The last time we discussed this (Andrew, Pavel and I), we've decided
that for ethernet PHY controlled LEDs we want the devicename part
should be something like
phyN or ethphyN or ethernet-phyN
with N a number unique for every PHY (a simple atomically increased
integer for every ethernet PHY). (This is because the LED pin is
physically connected to the PHY.)
But we can't do this here, because in the case of this igc driver, the
LEDs are controlled by the MAC, not the PHY (as far as I understand).
Which means that the LED is connected to a pin on the SOC or MAC chip.
Florian's suggestion is to use dev_name(), he says:
FWIW, dev_name() should be the "devicename" from what you described
above. This is foundational property for all devices that Linux
registers that is used for logging, name spacing within /sys/, uniqe,
ABI stable, etc. Anything different would be virtually impossible to
maintain and would lead to ABI breakage down the road, guaranteed.
I understand this point of view, since the purpose of dev_name() is
to represent devices in userspace. And for the purpose of LED devicename
part it works beautifully sometimes, for block devices for example,
where the dev_name() is be mmc0, sda1, ...
The problem is that for other kind of devices dev_name() may contain the
':' character (and often it does), which can break parsing LED names,
since the LED name format also contains colons:
devicename:color:function
So in the case of a block device, it works:
mmc0::
sda:red:read
dm-0::write
But for a PCIe network controller it may contain too many colons:
0000:02:00.0:yellow:activity
So basically this LED device naming scheme is the reason why we are
trying to make prettier names for LED trigger sources / controllers.
The possible solutions here are the following (the list is not
exhaustive):
- allow using devicenames containing ':' characters, i.e.
0000:02:00.0:yellow:activity
This can break existing userspace utilities (there are no official
ones, though). But IMO it should be a viable solution since we can
extract the devicename part, because we know that the color and
function parts do not contain colons.
- substitute ':' characters with a different character in the devicename
part
- use a prettier name, like we wanted to do with ethernet PHYs.
The question is what do we want to do for MAC (instead of PHY)
controlled LEDs, as is the case in this igc driver. We could introduce
a simple atomically increased integer for every MAC, the same we want
to do in the PHY case, so the devicename could be something like
macN (or ethmacN or ethernet-macN)
I confess that I am growing a little frustrated here, because there
seems to be no optimal solution with given constraints and no official
consensus for a suboptimal yet acceptable solution.
Marek
