From: Lee Jones <lee.jones@linaro.org>
To: Ian Pilcher <arequipeno@gmail.com>
Cc: pavel@ucw.cz, linux-leds@vger.kernel.org, kabel@kernel.org,
Lee Jones <lee@kernel.org>
Subject: Re: [PATCH v11 0/2] Introduce block device LED trigger
Date: Tue, 20 Sep 2022 09:34:43 +0100 [thread overview]
Message-ID: <Yyl7I5H157Eci5UI@google.com> (raw)
In-Reply-To: <20220915205018.447014-1-arequipeno@gmail.com>
On Thu, 15 Sep 2022, Ian Pilcher wrote:
> Summary
> =======
>
> These patches add a new "blkdev" LED trigger that blinks LEDs in
> response to disk (or other block device) activity. The first patch is
> purely documentation, and the second patch adds the trigger.
>
> It operates very much like the netdev trigger. Device activity
> counters are checked periodically, and LEDs are blinked if the correct
> type of activity has occurred since the last check. The trigger has no
> impact on the actual I/O path.
>
> The trigger is extremely configurable. An LED can be configured to
> blink in response to any type (or combination of types) of block device
> activity - reads, writes, discards, or cache flushes. The frequency
> with which device activity is checked and the duration of LED blinks
> can also be set.
>
> The trigger supports many-to-many "link" relationships between block
> devices and LEDs. An LED can be linked to multiple block devices, and
> a block device can be linked to multiple LEDs. To support these
> many-to-many links with a sysfs API, the trigger uses write-only
> attributes (link_dev_by_path and unlink_dev_by_path) to create and
> remove link relationships. Existing links are shown as symbolic links
> in subdirectories beneath the block device and LED sysfs directories
> (/sys/class/block/<DEVICE>/linked_leds and
> /sys/class/leds/<LED>/linked_devices).
>
> As their names indicate, link_dev_by_path and unlink_dev_by_path each
> take a device special file path (e.g. /dev/sda), rather than a kernel
> device name. This is required, because the block subsystem does not
> provide an API to get a block device by its kernel name; only device
> special file paths (or device major and minor numbers) are supported.
>
> (I hope that if this module is accepted, it might provide a case for
> adding a "by name" API to the block subsystem. link_dev_by_name and
> unlink_dev_by_name could then be added to this trigger.)
>
> The trigger can be built as a module or built in to the kernel.
My I ask how I ended up on Cc for this set please?
--
DEPRECATED: Please use lee@kernel.org
prev parent reply other threads:[~2022-09-20 8:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-15 20:50 [PATCH v11 0/2] Introduce block device LED trigger Ian Pilcher
2022-09-15 20:50 ` [PATCH v11 1/2] docs: Add block device (blkdev) LED trigger documentation Ian Pilcher
2022-09-21 11:05 ` Pavel Machek
2022-09-24 17:28 ` Ian Pilcher
2022-09-15 20:50 ` [PATCH v11 2/2] leds: trigger: Add block device LED trigger Ian Pilcher
2022-09-20 8:34 ` Lee Jones [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yyl7I5H157Eci5UI@google.com \
--to=lee.jones@linaro.org \
--cc=arequipeno@gmail.com \
--cc=kabel@kernel.org \
--cc=lee@kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).