| Message ID | 20210729015344.3366750-1-arequipeno@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add configurable block device LED triggers | expand |
Hi! > 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. That's not how this is normally done. We normally have a trigger ("block device activity") which can then expose parameters ("I watch for read" and "I monitor sda1"). Is there a reason normal solution can not be used? Best regards, Pavel
On 7/29/21 3:54 AM, Pavel Machek wrote: > We normally have a trigger ("block device activity") which can then > expose parameters ("I watch for read" and "I monitor sda1"). > > Is there a reason normal solution can not be used? This big difference is that this allows different devices to drive different LEDs. For example, my NAS has 5 drive bays, each of which has its own activity LED. With these patches, I can create a separate trigger for each of those LEDs and associate the drive in each bay with the correct LED: sdb --> trigger1 --> LED1 ⋮ ⋮ ⋮ sdf --> trigger5 --> LED5 (sda is the SATA DOM boot drive.) Note that this also supports associating multiple devices with a single trigger, so it can be used for more complicated schemes. For example, if my NAS had an additional LED and an optical drive, I could do this: sr0 --+ | +--> trigger0 --> LED0 | sda --+ sdb -----> trigger1 --> LED1 ⋮ ⋮ ⋮ sdf -----> trigger5 --> LED5 As far as I know, the current triggers (disk-activity, disk-read, disk-write, and ide-disk) don't support this sort of arbitrary device-trigger association. This patch set also support triggering LEDs from pretty much any block device (virtual as well as physical), not just ATA devices, although that's just a matter of the place from which the trigger is "fired". I hope this explains things. Thanks!
On Thu 2021-07-29 12:03:04, Ian Pilcher wrote: > On 7/29/21 3:54 AM, Pavel Machek wrote: > > We normally have a trigger ("block device activity") which can then > > expose parameters ("I watch for read" and "I monitor sda1"). > > > > Is there a reason normal solution can not be used? > > This big difference is that this allows different devices to drive > different LEDs. For example, my NAS has 5 drive bays, each of which > has its own activity LED. With these patches, I can create a > separate trigger for each of those LEDs and associate the drive in each > bay with the correct LED: Yes, and I'd like to have that functionality, but I believe userland API should be similar to what we do elsewhere. Marek described it in more details. Best regards, Pavel
On 7/29/21 1:35 PM, Pavel Machek wrote: > Yes, and I'd like to have that functionality, but I believe userland > API should be similar to what we do elsewhere. Marek described it in > more details. On 7/29/21 6:59 AM, Marek Behún wrote: ... > - only one trigger, with name "blkdev" I guess I'm missing something, because I just don't understand how this can work for multiple, per-device LEDs.
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