[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210920205626.288366-1-arequipeno@gmail.com>
Date: Mon, 20 Sep 2021 15:56:24 -0500
From: Ian Pilcher <arequipeno@...il.com>
To: pavel@....cz
Cc: linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org,
gregkh@...uxfoundation.org, kabel@...nel.org, hch@...radead.org
Subject: [PATCH v5 0/2] Introduce block device LED trigger
Changes from v4:
================
* Use xarrays, rather than lists, to model "links" between LEDs and block
devices. This allows many-to-many relationships without the need for a
separate link object.
* When resolving (getting) a block device by path, don't retry with
"/dev/" prepended to the path in the ENOENT case.
* Use an enum, rather than a boolean, to tell led_bdev_unlink() whether
the block device is being released or not.
* Use preprocessor constant, rather than magic number, for the mode passed
to blkdev_get_by_path() and blkdev_put().
* Split the data structure used by mode attribute show & store functions
into 2 separate arrays and move them into the functions that use them.
Changes from v3:
================
* Use blkdev_get_by_path() to "resolve" block devices
(struct block_device). With this change, there are now no changes
required to the block subsystem, so there are only 2 patches in this
series.
* link_device and unlink_device attributes now take paths to block device
special files (e.g. /dev/sda), rather than kernel names. Symbolic
links also work.
If the path written to the attribute doesn't exist (-ENOENT), we re-try
with /dev/ prepended, so "simple" names like sda will still work as long
as the corresponding special file exists in /dev.
* Fixed a bug that could cause "phantom" blinks because of old device
activity that was not recognized at the correct time.
* (Slightly) more detailed commit message for the patch that adds the
trigger code. As with v3, the real details are found in the comments
in the source file.
Changes from v2:
================
* Allow LEDs to be "linked" to partitions, as well as whole devices.
Internally, the trigger now works with block_device structs, rather
than gendisk structs.
(Investigating the lifecycle of block_device structs led me to
discover the device resource API, so ...)
* Use the device resource API to manage the trigger's per-block device
data structure (struct led_bdev_bdi). The trigger now uses a release
function to remove references to block devices that have been removed.
Because the release function is automatically called by the driver core,
there is no longer any need for the block layer to explictly call the
trigger's cleanup function.
* Since there is no need to provide a built-in "stub" cleanup function
when the trigger is built as a module, I have removed the always
built-in "core" portion of the trigger.
* Without a built-in component, the module does need access to the
block_class symbol. The second patch in this series exports the symbol
to the LEDTRIG_BLKDEV namespace and explains the reason for doing so.
* Changed the interval sysfs attribute from a device attribute to a class
attribute. It's single value that applies to all LEDs, so it didn't
make sense as a device atribute.
* As requested, I am posting the trigger code (ledtrig-blkdev.c) as a
single patch. This eliminates the commit messages that would otherwise
describe sections of the code, so I have added fairly extensive comments
to each function.
Changes from v1:
================
* Use correct address for LKML.
* Renamed the sysfs attributes used to manage and view the set of block
devices associated ("linked") with an LED.
- /sys/class/leds/<LED>/link_device to create associations
- /sys/class/leds/<LED>/unlink_device to remove associations
- /sys/class/leds/<LED>/linked_devices/ contains symlinks to all block
devices associated with the LED
- /sys/block/<DEVICE>/linked_leds (which only exists when the device is
associated with at least one LED) contains symlinks to all LEDs with
which the device is associated
link_device and unlink_device are write-only attributes, each of which
represents a single action, rather than any state. (The current state
is shown by the symbolic links in the <LED>/linked_devices/ and
<DEVICE>/linked_leds/ directories.)
* Simplified sysfs attribute store functions. link_device and
unlink_device no longer accept multiple devices at once, but this was
really just an artifact of the way that sysfs repeatedly calls the
store function when it doesn't "consume" all of its input, and it
seemed to be confusing and unpopular anyway.
* Use DEVICE_ATTR_* macros (rather than __ATTR) for the sysfs attributes.
* Removed all pr_info() "system administrator error" messages.
* Different minimum values for LED blink time (10 ms) and activity check
interval (25 ms).
v1 summary:
===========
This patch series adds a new "blkdev" LED trigger for disk (or other block
device) activity LEDs.
It has the following functionality.
* Supports all types of block devices, including virtual devices
(unlike the existing disk trigger which only works with ATA devices).
* LEDs can be configured to show read activity, write activity, or both.
* Supports multiple devices and multiple LEDs in arbitrary many-to-many
configurations. For example, it is possible to configure multiple
devices with device-specific read activity LEDs and a shared write
activity LED. (See Documentation/leds/ledtrig-blkdev.rst in the first
patch.)
* Doesn't add any overhead in the I/O path. Like the netdev LED trigger,
it periodically checks the configured devices for activity and blinks
its LEDs as appropriate.
* Blink duration (per LED) and interval between activity checks (global)
are configurable.
* Requires minimal changes to the block subsystem.
- Adds 1 pointer to struct gendisk,
- Adds (inline function) call in device_add_disk() to ensure that the
pointer is initialized to NULL (as protection against any drivers
that allocate a gendisk themselves and don't use kzalloc()), and
- Adds call in del_gendisk() to remove a device from the trigger when
that device is being removed.
These changes are all in patch #4, "block: Add block device LED trigger
integrations."
* The trigger can be mostly built as a module.
When the trigger is modular, a small portion is built in to provide a
"stub" function which can be called from del_gendisk(). The stub calls
into the modular code via a function pointer when needed. The trigger
also needs the ability to find gendisk's by name, which requires access
to the un-exported block_class and disk_type symbols.
*** BLURB HERE ***
Ian Pilcher (2):
docs: Add block device (blkdev) LED trigger documentation
leds: trigger: Add block device LED trigger
Documentation/ABI/testing/sysfs-block | 9 +
.../testing/sysfs-class-led-trigger-blkdev | 48 +
Documentation/leds/index.rst | 1 +
Documentation/leds/ledtrig-blkdev.rst | 148 +++
drivers/leds/trigger/Kconfig | 9 +
drivers/leds/trigger/Makefile | 1 +
drivers/leds/trigger/ledtrig-blkdev.c | 965 ++++++++++++++++++
7 files changed, 1181 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-blkdev
create mode 100644 Documentation/leds/ledtrig-blkdev.rst
create mode 100644 drivers/leds/trigger/ledtrig-blkdev.c
base-commit: e8f71f89236ef82d449991bfbc237e3cb6ea584f
--
2.31.1
Powered by blists - more mailing lists