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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.