From: Ian Pilcher <hidden> Date: 2021-07-29 01:54:32
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
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
From: Ian Pilcher <hidden> Date: 2021-07-29 01:54:38
* Document the sysfs attributes (/sys/class/block/led_trigger_*
and /sys/class/block/${DEV}/led_trigger) that can be used to
create, list, and delete block device LED triggers and to
set and clear device/trigger associations.
* Pull API documentation from block/blk-ledtrig.c (once it
exists).
Signed-off-by: Ian Pilcher <redacted>
---
Documentation/block/index.rst | 1 +
Documentation/block/led-triggers.rst | 124 +++++++++++++++++++++++++++
2 files changed, 125 insertions(+)
create mode 100644 Documentation/block/led-triggers.rst
@@ -0,0 +1,124 @@+.. SPDX-License-Identifier: GPL-2.0++============+LED Triggers+============++Available when ``CONFIG_BLK_LED_TRIGGERS=y``.++sysfs interface+===============++Create a new block device LED trigger::++ # echo foo > /sys/class/block/led_trigger_new++The name must be unique among all LED triggers (not just block device LED+triggers).++Create two more::++ # echo bar baz > /sys/class/block/led_trigger_new++List the triggers::++ # cat /sys/class/block/led_trigger_list+ baz: 0+ bar: 0+ foo: 0++(The number after each trigger is its reference count.)++Associate a trigger with a block device::++ # cat /sys/class/block/sda/led_trigger+ (none)++ # echo foo > /sys/class/block/sda/led_trigger+ # cat /sys/class/block/sda/led_trigger+ foo++Note that ``foo``'s reference count has increased, and it cannot be deleted::++ # cat /sys/class/block/led_trigger_list+ baz: 0+ bar: 0+ foo: 1++ # echo foo > /sys/class/block/led_trigger_del+ -bash: echo: write error: Device or resource busy++ # dmesg | tail -n 1+ [23176.475424] blockdev LED trigger foo still in use++Associate the ``foo`` trigger with an LED::++ # cat /sys/class/leds/input1::scrolllock/trigger+ none usb-gadget usb-host rc-feedback [kbd-scrolllock] kbd-numlock+ kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock+ kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock+ disk-activity disk-read disk-write ide-disk mtd nand-disk panic+ audio-mute audio-micmute rfkill-any rfkill-none foo bar baz++ # echo foo > /sys/class/leds/input1::scrolllock/trigger++ # cat /sys/class/leds/input1::scrolllock/trigger+ none usb-gadget usb-host rc-feedback [kbd-scrolllock] kbd-numlock+ kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock+ kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock+ disk-activity disk-read disk-write ide-disk mtd nand-disk panic+ audio-mute audio-micmute rfkill-any rfkill-none [foo] bar baz++Reads and writes to ``sda`` should now cause the scroll lock LED on your+keyboard to blink (assuming that it has one).++Multiple devices can be associated with a trigger::++ # echo foo > /sys/class/block/sdb/led_trigger++ # cat /sys/class/block/led_trigger_list+ baz: 0+ bar: 0+ foo: 2++Activity on either ``sda`` or ``sdb`` should now be shown by your scroll lock+LED.++Clear ``sda``'s LED trigger::++ # echo > /sys/class/block/sda/led_trigger++ # cat /sys/class/block/sda/led_trigger+ (none)++ # cat /sys/class/block/led_trigger_list+ baz: 0+ bar: 0+ foo: 1++And ``sdb``'s trigger::++ # echo > /sys/class/block/sdb/led_trigger++Delete the triggers::++ # echo foo bar baz > /sys/class/block/led_trigger_del++ # cat /sys/class/block/led_trigger_list++ # cat /sys/class/leds/input1::scrolllock/trigger+ none usb-gadget usb-host rc-feedback [kbd-scrolllock] kbd-numlock+ kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock+ kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock+ disk-activity disk-read disk-write ide-disk mtd nand-disk panic+ audio-mute audio-micmute rfkill-any rfkill-none++Also see **Userspace LEDs** (``Documentation/leds/uleds.rst``).++Kernel API+==========++``#include <linux/blk-ledtrig.h>``++..kernel-doc:: block/blk-ledtrig.c+:export:
--
2.31.1
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
From: Ian Pilcher <hidden> Date: 2021-07-29 01:54:38
* New config option (CONFIG_BLK_LED_TRIGGERS) to enable/disable
block device LED triggers
* New file - block/blk-ledtrig.c
* Use a linked list of dynamically allocated triggers. There
aren't likely to be that many of them, and the list is only
searched when creating/deleting a trigger or setting/clearing
a device/trigger association - none of which should occur very
often.
Signed-off-by: Ian Pilcher <redacted>
---
block/Kconfig | 10 +++++++++
block/Makefile | 1 +
block/blk-ledtrig.c | 51 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 62 insertions(+)
create mode 100644 block/blk-ledtrig.c
@@ -0,0 +1,51 @@+// SPDX-License-Identifier: GPL-2.0-only++/*+*BlockdeviceLEDtriggers+*+*Copyright2021IanPilcher<arequipeno@gmail.com>+*/++#include<linux/leds.h>+#include<linux/list.h>+#include<linux/mutex.h>+++/*+*+*ThelistofblockdeviceLEDtriggers+*+*/++structblk_ledtrig{+structled_triggertrigger;+structlist_headlist_node;+structmutexrefcount_mutex;+intrefcount;+charname[];+};++LIST_HEAD(blk_ledtrig_list);+DEFINE_MUTEX(blk_ledtrig_list_mutex);++staticinline+structblk_ledtrig*blk_ledtrig_from_node(structlist_head*constnode)+{+returncontainer_of(node,structblk_ledtrig,list_node);+}++// Caller must hold blk_ledtrig_list_mutex+staticstructblk_ledtrig*blk_ledtrig_find(constchar*constname,+constsize_tlen)+{+structblk_ledtrig*t;+structlist_head*n;++list_for_each(n,&blk_ledtrig_list){+t=blk_ledtrig_from_node(n);+if(strlen(t->name)==len&&memcmp(name,t->name,len)==0)+returnt;+}++returnNULL;+}
--
2.31.1
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
@@ -49,3 +51,153 @@ static struct blk_ledtrig *blk_ledtrig_find(const char *const name,returnNULL;}+++/*+*+*Createanewtrigger+*+*/++staticint__blk_ledtrig_create(constchar*constname,constsize_tlen)+{+structblk_ledtrig*t;+intret;++if(len==0){+pr_warn("empty name specified for blockdev LED trigger\n");+ret=-EINVAL;+gotocreate_exit_return;+}++ret=mutex_lock_interruptible(&blk_ledtrig_list_mutex);+if(unlikely(ret!=0))+gotocreate_exit_return;++if(blk_ledtrig_find(name,len)!=NULL){+pr_warn("blockdev LED trigger named %.*s already exists\n",+(int)len,name);+ret=-EEXIST;+gotocreate_exit_unlock_list;+}++t=kzalloc(sizeof(*t)+len+1,GFP_KERNEL);+if(unlikely(t==NULL)){+ret=-ENOMEM;+gotocreate_exit_unlock_list;+}++memcpy(t->name,name,len);+t->trigger.name=t->name;+mutex_init(&t->refcount_mutex);++ret=led_trigger_register(&t->trigger);+if(ret!=0){+if(likely(ret==-EEXIST)){+pr_warn("LED trigger named %.*s already exists\n",+(int)len,name);+}+gotocreate_exit_free;+}++list_add(&t->list_node,&blk_ledtrig_list);+ret=0;++create_exit_free:+if(ret!=0)+kfree(t);+create_exit_unlock_list:+mutex_unlock(&blk_ledtrig_list_mutex);+create_exit_return:+returnret;+}++/**+*blk_ledtrig_create()-createsanewblockdeviceLEDtrigger+*@name:thenameofthenewtrigger+*+*Context:Processcontext(cansleep).Takesandreleases+*@blk_ledtrig_list_mutex.+*+*Return:0onsuccess;-@errnoonerror+*/+intblk_ledtrig_create(constchar*constname)+{+return__blk_ledtrig_create(name,strlen(name));+}+EXPORT_SYMBOL_GPL(blk_ledtrig_create);+++/*+*+*Deleteatrigger+*+*/++staticint__blk_ledtrig_delete(constchar*constname,constsize_tlen)+{+structblk_ledtrig*t;+intret;++if(len==0){+pr_warn("empty name specified for blockdev LED trigger\n");+ret=-EINVAL;+gotodelete_exit_return;+}++ret=mutex_lock_interruptible(&blk_ledtrig_list_mutex);+if(unlikely(ret!=0))+gotodelete_exit_return;++t=blk_ledtrig_find(name,len);+if(t==NULL){+pr_warn("blockdev LED trigger named %.*s doesn't exist\n",+(int)len,name);+ret=-ENODEV;+gotodelete_exit_unlock_list;+}++ret=mutex_lock_interruptible(&t->refcount_mutex);+if(unlikely(ret!=0))+gotodelete_exit_unlock_list;++if(WARN_ON(t->refcount<0)){+ret=-EBADFD;+gotodelete_exit_unlock_refcount;+}++if(t->refcount>0){+pr_warn("blockdev LED trigger %s still in use\n",t->name);+ret=-EBUSY;+gotodelete_exit_unlock_refcount;+}++led_trigger_unregister(&t->trigger);+list_del(&t->list_node);++ret=0;++delete_exit_unlock_refcount:+mutex_unlock(&t->refcount_mutex);+if(ret==0)+kfree(t);+delete_exit_unlock_list:+mutex_unlock(&blk_ledtrig_list_mutex);+delete_exit_return:+returnret;+}++/**+*blk_ledtrig_delete()-deletesablockdeviceLEDtrigger+*@name:thenameofthetriggertobedeleted+*+*Context:Processcontext(cansleep).Takesandreleases+*@blk_ledtrig_list_mutexandtrigger's@refcount_mutex.+*+*Return:0onsuccess;-@errnoonerror+*/+intblk_ledtrig_delete(constchar*constname)+{+return__blk_ledtrig_delete(name,strlen(name));+}+EXPORT_SYMBOL_GPL(blk_ledtrig_delete);
@@ -201,3 +205,146 @@ int blk_ledtrig_delete(const char *const name)return__blk_ledtrig_delete(name,strlen(name));}EXPORT_SYMBOL_GPL(blk_ledtrig_delete);+++/*+*+*Classattributestomanagethetriggerlist+*+*/++staticssize_tblk_ledtrig_attr_store(structclass*,structclass_attribute*,+constchar*,constsize_t);+staticssize_tblk_ledtrig_list_show(structclass*,structclass_attribute*,+char*);++staticstructclass_attributeblk_ledtrig_attr_new=+__ATTR(led_trigger_new,0200,0,blk_ledtrig_attr_store);++staticstructclass_attributeblk_ledtrig_attr_del=+__ATTR(led_trigger_del,0200,0,blk_ledtrig_attr_store);++staticstructclass_attributeblk_ledtrig_attr_list=+__ATTR(led_trigger_list,0444,blk_ledtrig_list_show,0);++// Returns a pointer to the first non-whitespace character in s (or a pointer+// to the terminating nul).+staticconstchar*blk_ledtrig_skip_whitespace(constchar*s)+{+while(*s!=0&&isspace(*s))+++s;++returns;+}++// Returns a pointer to the first whitespace character in s (or a pointer to+// the terminating nul), which is effectively a pointer to the position *after*+// the last character in the non-whitespace token at the beginning of s. (s is+// expected to be the result of a previous call to blk_ledtrig_skip_whitespace.)+staticconstchar*blk_ledtrig_find_whitespace(constchar*s)+{+while(*s!=0&&!isspace(*s))+++s;++returns;+}++staticssize_tblk_ledtrig_attr_store(structclass*constclass,+structclass_attribute*constattr,+constchar*constbuf,+constsize_tcount)+{+constchar*constname=blk_ledtrig_skip_whitespace(buf);+constchar*constendp=blk_ledtrig_find_whitespace(name);+constptrdiff_tname_len=endp-name;// always >= 0+intret;++if(attr==&blk_ledtrig_attr_new)+ret=__blk_ledtrig_create(name,name_len);+else// attr == &blk_ledtrig_attr_del+ret=__blk_ledtrig_delete(name,name_len);++if(ret<0)+returnret;++// Avoid potential "empty name" error by skipping whitespace+// to next token or terminating nul+returnblk_ledtrig_skip_whitespace(endp)-buf;+}++staticssize_tblk_ledtrig_list_show(structclass*constclass,+structclass_attribute*constattr,+char*constbuf)+{+structlist_head*n;+intret,c=0;++ret=mutex_lock_interruptible(&blk_ledtrig_list_mutex);+if(unlikely(ret!=0))+gotolist_exit_return;++list_for_each(n,&blk_ledtrig_list){++structblk_ledtrig*constt=blk_ledtrig_from_node(n);+intrefcount;++ret=mutex_lock_interruptible(&t->refcount_mutex);+if(unlikely(ret!=0))+gotolist_exit_unlock_list;++refcount=t->refcount;++mutex_unlock(&t->refcount_mutex);++ret=snprintf(buf+c,PAGE_SIZE-c,"%s: %d\n",+t->name,refcount);+if(unlikely(ret<0))+gotolist_exit_unlock_list;++c+=ret;+if(unlikely(c>=PAGE_SIZE)){+ret=-EOVERFLOW;+gotolist_exit_unlock_list;+}+}++ret=c;++list_exit_unlock_list:+mutex_unlock(&blk_ledtrig_list_mutex);+list_exit_return:+returnret;+}+++/*+*+*Initialization-createtheclassattributes+*+*/++void__initblk_ledtrig_init(void)+{+intret;++ret=class_create_file(&block_class,&blk_ledtrig_attr_new);+if(unlikely(ret!=0))+gotoinit_error_new;++ret=class_create_file(&block_class,&blk_ledtrig_attr_del);+if(unlikely(ret!=0))+gotoinit_error_del;++ret=class_create_file(&block_class,&blk_ledtrig_attr_list);+if(unlikely(ret!=0))+gotoinit_error_list;++return;++init_error_list:+class_remove_file(&block_class,&blk_ledtrig_attr_del);+init_error_del:+class_remove_file(&block_class,&blk_ledtrig_attr_new);+init_error_new:+pr_err("failed to initialize blkdev LED triggers (%d)\n",ret);+}
From: Ian Pilcher <hidden> Date: 2021-07-29 01:54:47
* Clear LED trigger (decrement trigger reference count) when device
is deleted, e.g. when a USB disk is unplugged.
Signed-off-by: Ian Pilcher <redacted>
---
block/blk-ledtrig.c | 131 ++++++++++++++++++++++++++++++++++++
block/blk-ledtrig.h | 5 ++
block/genhd.c | 2 +
include/linux/blk-ledtrig.h | 5 ++
4 files changed, 143 insertions(+)
@@ -348,3 +348,134 @@ void __init blk_ledtrig_init(void)init_error_new:pr_err("failed to initialize blkdev LED triggers (%d)\n",ret);}+++/*+*+*Setadevicetrigger+*+*/++staticint__blk_ledtrig_set(structgendisk*constgd,constchar*constname,+constsize_tname_len)+{+structblk_ledtrig*t;+boolalready_set;+intret;++ret=mutex_lock_interruptible(&blk_ledtrig_list_mutex);+if(unlikely(ret!=0))+gotoset_exit_return;++t=blk_ledtrig_find(name,name_len);+if(t==NULL){+pr_warn("blockdev LED trigger named %.*s doesn't exist\n",+(int)name_len,name);+ret=-ENODEV;+gotoset_exit_unlock_list;+}++ret=mutex_lock_interruptible(&t->refcount_mutex);+if(unlikely(ret!=0))+gotoset_exit_unlock_list;++// Holding the refcount mutex blocks __blk_ledtrig_delete, so we don't+// actually need to hold the list mutex anymore, but it makes the flow+// much simpler to do so++if(WARN_ON_ONCE(t->refcount==INT_MAX)){+ret=-ERANGE;+gotoset_exit_unlock_refcount;+}++ret=mutex_lock_interruptible(&gd->ledtrig_mutex);+if(unlikely(ret!=0))+gotoset_exit_unlock_refcount;++if(gd->ledtrig==NULL){+already_set=false;+gd->ledtrig=t;+}else{+already_set=true;+}++mutex_unlock(&gd->ledtrig_mutex);++if(already_set){+pr_warn("blockdev trigger for %s already set\n",+gd->disk_name);+ret=-EBUSY;+gotoset_exit_unlock_refcount;+}++++(t->refcount);+ret=0;++set_exit_unlock_refcount:+mutex_unlock(&t->refcount_mutex);+set_exit_unlock_list:+mutex_unlock(&blk_ledtrig_list_mutex);+set_exit_return:+returnret;+}++/**+*blk_ledtrig_set()-settheLEDtriggerforablockdevice+*@gd:theblockdevice+*@name:thenameoftheLEDtrigger+*+*Context:Processcontext(cansleep).Takesandreleases+*@blk_ledtrig_list_mutex,trigger's@refcount_mutex,+*and@gd->ledtrig_mutex.+*+*Return:0onsuccess;-@errnoonerror+*/+intblk_ledtrig_set(structgendisk*constgd,constchar*constname)+{+return__blk_ledtrig_set(gd,name,strlen(name));+}+EXPORT_SYMBOL_GPL(blk_ledtrig_set);+++/*+*+*Clearadevicetrigger+*+*/++/**+*blk_ledtrig_clear()-cleartheLEDtriggerofablockdevice+*@gd:theblockdevice+*+*Context:Processcontext(cansleep).Takesandreleases+*@gd->ledtrig_mutexand@gd->ledtrig->refcount_mutex.+*+*Return:@trueifthetriggerwasactuallycleared;@falseifitwasn'tset+*/+boolblk_ledtrig_clear(structgendisk*constgd)+{+structblk_ledtrig*t;+boolchanged;+intnew_refcount;++mutex_lock(&gd->ledtrig_mutex);++t=gd->ledtrig;+if(t==NULL){+changed=false;+gotoclear_exit_unlock_ledtrig;+}++mutex_lock(&t->refcount_mutex);+new_refcount=--(t->refcount);+mutex_unlock(&t->refcount_mutex);++gd->ledtrig=NULL;+changed=true;++clear_exit_unlock_ledtrig:+mutex_unlock(&gd->ledtrig_mutex);+WARN_ON(changed&&(new_refcount<0));+returnchanged;+}+EXPORT_SYMBOL_GPL(blk_ledtrig_clear);
@@ -24,6 +24,11 @@ static inline void blk_ledtrig_disk_init(struct gendisk *const gd)staticinlinevoidblk_ledtrig_init(void){}staticinlinevoidblk_ledtrig_disk_init(conststructgendisk*gd){}+// Real function (declared in include/linux/blk-ledtrig.h) returns a bool.+// This is only here for del_gendisk() (in genhd.c), which doesn't check+// the return value.+staticinlinevoidblk_ledtrig_clear(conststructgendisk*gd){}+#endif // CONFIG_BLK_LED_TRIGGERS#endif // _BLOCK_BLK_LEDTRIG_H
From: Ian Pilcher <hidden> Date: 2021-07-29 01:54:49
* Don't wait to lock the device's LED trigger mutex; just don't
blink the LED this time if it can't be locked right away, i.e.
if mutex_trylock() fails.
Signed-off-by: Ian Pilcher <redacted>
---
block/blk-ledtrig.c | 24 ++++++++++++++++++++++++
block/blk-ledtrig.h | 9 +++++++++
block/blk-mq.c | 2 ++
3 files changed, 35 insertions(+)
@@ -27,10 +27,19 @@ ssize_t blk_ledtrig_devattr_show(struct device *const dev,structdevice_attribute*constattr,char*constbuf);+void__blk_ledtrig_try_blink(structgendisk*gd);++staticinlinevoidblk_ledtrig_try_blink(structgendisk*constgd)+{+if(gd!=NULL)+__blk_ledtrig_try_blink(gd);+}+#else // CONFIG_BLK_LED_TRIGGERSstaticinlinevoidblk_ledtrig_init(void){}staticinlinevoidblk_ledtrig_disk_init(conststructgendisk*gd){}+staticinlinevoidblk_ledtrig_try_blink(conststructgendisk*gd){}// Real function (declared in include/linux/blk-ledtrig.h) returns a bool.// This is only here for del_gendisk() (in genhd.c), which doesn't check
On Wed, 28 Jul 2021 20:53:37 -0500, Ian Pilcher said:
+Create a new block device LED trigger::
+
+ # echo foo > /sys/class/block/led_trigger_new
+
+The name must be unique among all LED triggers (not just block device LED
+triggers).
+
+Create two more::
+
+ # echo bar baz > /sys/class/block/led_trigger_new
This looks like an abuse of the "one entry one value" rule for sysfs.
Perhaps this should be a directory /sys/class/block/defined_triggers/
and separate files under that for foo, bar, and baz? That would probably
make reference counting a lot easier as well....
On Wed, 28 Jul 2021 20:53:38 -0500, Ian Pilcher said:
* New config option (CONFIG_BLK_LED_TRIGGERS) to enable/disable
block device LED triggers
* New file - block/blk-ledtrig.c
Is this bisect-clean (as in "will it build properly with that config option
set after each of the succeeding patches")? Usually, the config option
is added in the *last* patch, so that even if you have a bisect issue
it won't manifest because it's wrapped in a '#ifdef CONFIG_WHATEVER'
that can't possibly be compiled in because there's no way for Kconfig
to set that variable.
+
+static int __blk_ledtrig_create(const char *const name, const size_t len)
(...)
+ if (blk_ledtrig_find(name, len) != NULL) {
+ pr_warn("blockdev LED trigger named %.*s already exists\n",
+ (int)len, name);
Is pr_warn() the right level for this stuff? I'd think this sort of pilot error should
be pr_info() or even pr_debug(), if mentioned at all. pr_warn() would be for
something like an unexpected situation like trying to blink an LED but failing.
Simple syntax errors should probably just toss a -EINVAL and return.
(Among other things, this allows a userspace script to spam the
log by simply repeatedly trying to create the same entry)
@@ -49,3 +51,153 @@ static struct blk_ledtrig *blk_ledtrig_find(const char *const name,returnNULL;}+++/*+*+*Createanewtrigger+*+*/++staticint__blk_ledtrig_create(constchar*constname,constsize_tlen)+{+structblk_ledtrig*t;+intret;++if(len==0){+pr_warn("empty name specified for blockdev LED trigger\n");+ret=-EINVAL;+gotocreate_exit_return;+}++ret=mutex_lock_interruptible(&blk_ledtrig_list_mutex);+if(unlikely(ret!=0))
Only ever use likely/unlikely if you can measure the difference without
it. Otherwise the CPU and compiler will almost always get it right and
you should not clutter up the code with them at all.
For something like this function, where there is no speed difference at
all, there is no need for these types of markings, so I would recommend
just removing them all from your patchset.
thanks,
greg k-h
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Wed, Jul 28, 2021 at 08:53:37PM -0500, Ian Pilcher wrote:
* Document the sysfs attributes (/sys/class/block/led_trigger_*
and /sys/class/block/${DEV}/led_trigger) that can be used to
create, list, and delete block device LED triggers and to
set and clear device/trigger associations.
sysfs apis belong in Documentation/ABI/ like all other entries.
quoted hunk
* Pull API documentation from block/blk-ledtrig.c (once it
exists).
Signed-off-by: Ian Pilcher <redacted>
---
Documentation/block/index.rst | 1 +
Documentation/block/led-triggers.rst | 124 +++++++++++++++++++++++++++
2 files changed, 125 insertions(+)
create mode 100644 Documentation/block/led-triggers.rst
@@ -0,0 +1,124 @@+.. SPDX-License-Identifier: GPL-2.0++============+LED Triggers+============++Available when ``CONFIG_BLK_LED_TRIGGERS=y``.++sysfs interface+===============++Create a new block device LED trigger::++ # echo foo > /sys/class/block/led_trigger_new++The name must be unique among all LED triggers (not just block device LED+triggers).++Create two more::++ # echo bar baz > /sys/class/block/led_trigger_new++List the triggers::++ # cat /sys/class/block/led_trigger_list+ baz: 0+ bar: 0+ foo: 0
On Wed, Jul 28, 2021 at 08:53:40PM -0500, Ian Pilcher wrote:
* New class attributes - /sys/class/block/led_trigger_{new,list,del}
* Add init function - blk_ledtrig_init() - to create the attributes
in sysfs. Call blk_ledtrig_init() from genhd_device_init() (in
block/genhd.c).
* New file - block/blk-ledtrig.h
That is an odd way to write a changelog, please read the documentation
file about how to write a good changelog.
thanks,
greg k-h
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
From: Pavel Machek <hidden> Date: 2021-07-29 08:54:21
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
--
http://www.livejournal.com/~pavelmachek
From: Marek Behún <kabel@kernel.org> Date: 2021-07-29 12:00:02
Dear Ian,
On Wed, 28 Jul 2021 20:53:37 -0500
Ian Pilcher [off-list ref] wrote:
* Document the sysfs attributes (/sys/class/block/led_trigger_*
and /sys/class/block/${DEV}/led_trigger) that can be used to
create, list, and delete block device LED triggers and to
set and clear device/trigger associations.
* Pull API documentation from block/blk-ledtrig.c (once it
exists).
Signed-off-by: Ian Pilcher <redacted>
thank you for this proposal.
I don't really see the purpose for having multiple different block
device LED triggers. Moreover we really do not want userspace to be
able to add LED triggers with arbitrary names, and as many as the
userspace wants. There is no sense in making userspace be able to
create 10000 triggers. Also if userspace can create triggers with
arbitrary names, it could "steal" a name for a real trigger. For
example if netdev trigger is compiled as a module, and before loading
someone creates blockdev trigger with name "netdev", the loading of
netdev trigger will fail.
I would like the blkdev trigger to work in a similar way the netdev
trigger works:
- only one trigger, with name "blkdev"
- when activated on a LED, new sysfs files will be created:
* device_name, where user can write sda1, vdb, ...
* read (binary value, 1 means blink on read)
* write (binary value, 1 means blink on write)
* interval (blink interval)
Note that device_name could allow multiple names, in theory...
Also some other disk states may be included, like error, or something
- also the blinking itself can be done as is done netdev trigger: every
50ms the work function would look at blkdev stats, and if current
stat (number of bytes read/written) is different from previous, then
blink the LED
Marek
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
This looks like an abuse of the "one entry one value" rule for sysfs.
Perhaps this should be a directory /sys/class/block/defined_triggers/
and separate files under that for foo, bar, and baz? That would probably
make reference counting a lot easier as well....
Indeed it is.
Funny that you should mention using a subdirectory. I originally wanted
to put all of the trigger-related stuff into
/sys/class/block/led_triggers/, but I couldn't find any API to create a
subdirectory for *class* attributes (only for device attributes), nor do
I see any such subdirectories on my system.
# find /sys/class -type d | egrep '^/sys/class/[^/]+/'
(no output)
Is is possible to create subdirectories for class attributes?
--
========================================================================
In Soviet Russia, Google searches you!
========================================================================
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
From: Ian Pilcher <hidden> Date: 2021-07-29 15:55:29
On 7/28/21 10:14 PM, Valdis Klētnieks wrote:
Is this bisect-clean (as in "will it build properly with that config option
set after each of the succeeding patches")? Usually, the config option
is added in the *last* patch, so that even if you have a bisect issue
it won't manifest because it's wrapped in a '#ifdef CONFIG_WHATEVER'
that can't possibly be compiled in because there's no way for Kconfig
to set that variable.
Yes it is. I tested compiling each patch with the CONFIG option both
enabled and disabled. (You will get an unused function warning for
blk_ledtrig_find() until patch #3 is applied.)
I'll switch to adding the option in the last patch of the series in the
future.
Thanks!
--
========================================================================
In Soviet Russia, Google searches you!
========================================================================
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
From: Ian Pilcher <hidden> Date: 2021-07-29 16:16:50
On 7/28/21 10:45 PM, Valdis Klētnieks wrote:
Is pr_warn() the right level for this stuff? I'd think this sort of pilot error should
be pr_info() or even pr_debug(), if mentioned at all. pr_warn() would be for
something like an unexpected situation like trying to blink an LED but failing.
Simple syntax errors should probably just toss a -EINVAL and return.
Fair point. I'll change it to pr_info(). I'm reluctant to completely
"swallow" the error message, as I've been on the other side as a system
administrator trying to guess at the reason for an error code.
(Among other things, this allows a userspace script to spam the
log by simply repeatedly trying to create the same entry)
Only root, and they've got plenty of ways to do that.
Thanks!
--
========================================================================
In Soviet Russia, Google searches you!
========================================================================
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
From: Ian Pilcher <hidden> Date: 2021-07-29 17:03:10
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!
--
========================================================================
In Soviet Russia, Google searches you!
========================================================================
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
From: Ian Pilcher <hidden> Date: 2021-07-29 18:03:41
On 7/29/21 6:59 AM, Marek Behún wrote:
I don't really see the purpose for having multiple different block
device LED triggers.
Is there a different/better way to control per-device LEDs? (I'm
thinking of something like my NAS, which has 5 drive bays, each with
its own activity LED.)
Moreover we really do not want userspace to be
able to add LED triggers with arbitrary names, and as many as the
userspace wants.
To be slightly flippant, why not? "Userspace" in this case is the
system/device administrator. They presumably know what LEDs they have
and what they want to use them for, something which the kernel cannot
know (assuming a "generic" disto kernel).
There is no sense in making userspace be able to
create 10000 triggers.
It would certainly be possible to impose a limit on the number of
triggers that could be created. But then someone has to decide what
that limit should be. Personally, I lean very much toward giving the
system administrator the freedom to configure their system as they see
fit, even if that means that they can break it. (Where "break"
basically means that they need to reboot.)
Also if userspace can create triggers with
arbitrary names, it could "steal" a name for a real trigger. For
example if netdev trigger is compiled as a module, and before loading
someone creates blockdev trigger with name "netdev", the loading of
netdev trigger will fail.
Would adding a prefix to the LED trigger name address your concern
about arbitrary names and potential conflicts? I.e. the system
administrator creates a block device LED trigger named "foo", and it
shows up as an LED trigger named "blkdev:foo" (or something like that).
I would like the blkdev trigger to work in a similar way the netdev
trigger works:
- only one trigger, with name "blkdev"
- when activated on a LED, new sysfs files will be created:
* device_name, where user can write sda1, vdb, ...
* read (binary value, 1 means blink on read)
* write (binary value, 1 means blink on write)
* interval (blink interval)
Note that device_name could allow multiple names, in theory...
Also some other disk states may be included, like error, or something
How would you support multiple, per-device LEDs (the NAS use case above)
in this scheme?
- also the blinking itself can be done as is done netdev trigger: every
50ms the work function would look at blkdev stats, and if current
stat (number of bytes read/written) is different from previous, then
blink the LED
Is there a reason that you prefer this approach to simply having the
block layer "fire" the trigger?
Thanks for the feedback!
--
========================================================================
In Soviet Russia, Google searches you!
========================================================================
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
From: Pavel Machek <hidden> Date: 2021-07-29 18:35:46
On Thu 2021-07-29 12:03:04, Ian Pilcher wrote:
On 7/29/21 3:54 AM, Pavel Machek wrote:
quoted
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
--
http://www.livejournal.com/~pavelmachek
From: Ian Pilcher <hidden> Date: 2021-07-29 19:14:29
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.
--
========================================================================
In Soviet Russia, Google searches you!
========================================================================
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
This looks like an abuse of the "one entry one value" rule for sysfs.
Perhaps this should be a directory /sys/class/block/defined_triggers/
and separate files under that for foo, bar, and baz? That would probably
make reference counting a lot easier as well....
Indeed it is.
Funny that you should mention using a subdirectory. I originally wanted
to put all of the trigger-related stuff into
/sys/class/block/led_triggers/, but I couldn't find any API to create a
subdirectory for *class* attributes (only for device attributes), nor do
I see any such subdirectories on my system.
Add a name to your attribute group and sysfs creates the subdirectory
automagically for you.
thanks,
greg k-h
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies