Date:   Tue, 27 Jul 2021 02:06:19 +0200
From:   Marek Behún <kabel@...nel.org>
To:     Heiner Kallweit <hkallweit1@...il.com>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Andrew Lunn <andrew@...n.ch>, Pavel Machek <pavel@....cz>,
        Florian Fainelli <f.fainelli@...il.com>
Cc:     Tony Nguyen <anthony.l.nguyen@...el.com>, davem@...emloft.net,
        kuba@...nel.org, Kurt Kanzenbach <kurt@...utronix.de>,
        netdev@...r.kernel.org, sasha.neftin@...el.com,
        vitaly.lifshits@...el.com, vinicius.gomes@...el.com,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Dvora Fuxbrumer <dvorax.fuxbrumer@...ux.intel.com>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>
Subject: Re: [PATCH net-next 5/5] igc: Export LEDs

Hi Heiner (and Pavel and Florian and others),

On Mon, 26 Jul 2021 22:59:05 +0200
Heiner Kallweit <hkallweit1@...il.com> 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

Powered by blists - more mailing lists