Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Ian Pilcher <arequipeno@gmail.com>
To:     linux-block@vger.kernel.org, linux-leds@vger.kernel.org
Cc:     axboe@kernel.dk, pavel@ucw.cz, linux-kernel@vger.kernel.org,
        kernelnewbies@kernelnewbies.org, Ian Pilcher <arequipeno@gmail.com>
Subject: [RFC PATCH 0/8] Add configurable block device LED triggers
Date:   Wed, 28 Jul 2021 20:53:36 -0500
Message-Id: <20210729015344.3366750-1-arequipeno@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

This patch series adds configurable (i.e. user-defined) block device LED
triggers.

* Triggers can be created, listed, and deleted via sysfs block class
  attributes (led_trigger_{new,list,del}).

* Once created, block device LED triggers are associated with LEDs just
  like any other LED trigger (via /sys/class/leds/${LED}/trigger).

* Each block device gains a new device attribute (led_trigger) that can
  be used to associate the device with a trigger or clear its
  association.

* My expectation is that most configuration will be done via sysfs
  (driven by udev), but there also in-kernel APIs for creating,
  deleting, and (dis)associating triggers.

* Multiple devices can be associated with one trigger, so this supports
  a single LED driven by multiple devices, multiple device-specific
  LEDs, or arbitrary combinations.

  Along with support for more than just ATA devices, this is the main
  difference between this function and the current disk activity
  trigger.  It makes it suitable for use on systems like the Thecus
  N5550 NAS, which has a software-driven activity LEDs for each disk.

* In addition to physical block devices, many types of virtual block
  devices can drive LEDs; device mapper, MD RAID, and loop devices
  work (but zram swap devices do not).

* The led trigger is "blinked" (75 msec on, 25 msec off) when a request
  is successfully sent to the low-level driver.  The intent is to
  provide a visual indication of device activity, not any sort of exact
  measurement.

* Related to the previous bullet, if the blink function is unable to
  immediately acquire a lock on the device's LED trigger information
  it simply returns, so that I/O processing can continue.

It's probably obvious that I'm basically a complete newbie at kernel
development, so I welcome feedback.

Thanks!

Ian Pilcher (8):
  docs: Add block device LED trigger documentation
  block: Add block device LED trigger list
  block: Add kernel APIs to create & delete block device LED triggers
  block: Add block class attributes to manage LED trigger list
  block: Add block device LED trigger info to struct genhd
  block: Add kernel APIs to set & clear per-block device LED triggers
  block: Add block device attributes to set & clear LED triggers
  block: Blink device LED when request is sent to low-level driver

 Documentation/block/index.rst        |   1 +
 Documentation/block/led-triggers.rst | 124 ++++++
 block/Kconfig                        |  10 +
 block/Makefile                       |   1 +
 block/blk-ledtrig.c                  | 570 +++++++++++++++++++++++++++
 block/blk-ledtrig.h                  |  51 +++
 block/blk-mq.c                       |   2 +
 block/genhd.c                        |  14 +
 include/linux/blk-ledtrig.h          |  24 ++
 include/linux/genhd.h                |   4 +
 10 files changed, 801 insertions(+)
 create mode 100644 Documentation/block/led-triggers.rst
 create mode 100644 block/blk-ledtrig.c
 create mode 100644 block/blk-ledtrig.h
 create mode 100644 include/linux/blk-ledtrig.h

-- 
2.31.1