On Monday 09 August 2021 20:56:33 Marek Behún wrote:

Hello Ian,

thank you for your proposal. Some comments below:

On Sun,  8 Aug 2021 22:32:07 -0500
Ian Pilcher [off-list ref] wrote:

quoted

One thing that has not changed is that associations between block
devices and LEDs are still set via an attribute on the device, rather
than the LED.  This is much simpler, as the device attribute only has
to handle a single value (the name of the associated LED), rather than
potentially handling multiple device names.

It may be simpler, but it is in contrast to how the netdev trigger
works, which already is in upstream for many years. I really think we
should try to have similar sysfs ABIs here. (I understand that the
netdev trigger is currently unable to handle multiple network
interfaces - but it is possible to extend it so.)

quoted

I have modeled the interface for the /sys/block/<DEVICE>/led
attribute on the sysfs interface used for selecting a trigger.  All
available LEDs (all LEDs associated with the blkdev trigger) are
shown when the attribute is read, with the currently selected LED
enclosed in square brackets ([]).

I think it is reasonable to be able to set something like this:
  led0 : blink on activity on any of [sda, sdb, sdc]
  led1 : blink on activity on sda
  led2 : blink on activity on sdb
  led3 : blink on activity on sdc

If I am reading your code correctly, it looks that only one LED can be
configured for a block device. Is this true? If so, then the above
configuration cannot be set.

Also you are blinking the LED on any request to the block device. I
would rather expect to be able to set the LED to blink on read and on
write. (And possibly on other functions, like discard, or critical
temperature, or error, ...) I would like to know what other people
think about this.

Hello!

HP EliteBook laptops had dedicated LED for some kind of error and
encryption indication. And there is kernel acpi/wmi driver which can
control this LED. I do not know if recent HP laptops still have these
LEDs, but I would suggest to design API in a way that would allow to use
these dedicated LEDs for their original "vendor" purpose.

I'm mentioning it just because this functionality and design is already
on existing production mainstream laptops, and not something imaginary.

If Linux distributions are still cooperating with laptop vendors and
doing "official" Linux preloads then they may be interested in having
"native" LED functionality support in kernel.