Marek - Thanks for taking the time to look at this. On 8/9/21 1:56 PM, Marek Behún wrote:
It may be simpler, but it is in contrast to how the netdev trigger works, which already is in upstream for many years. I really think we should try to have similar sysfs ABIs here. (I understand that the netdev trigger is currently unable to handle multiple network interfaces - but it is possible to extend it so.)
I'm not unalterably opposed to the idea, but I don't currently see a way to do that without resolving block devices (struct gendisk) by name, and that seems to be a no-no. If you (or anyone else) has a suggestion on how to get around this obstacle, I'd be willing to give it a shot.
I think it is reasonable to be able to set something like this: led0 : blink on activity on any of [sda, sdb, sdc] led1 : blink on activity on sda led2 : blink on activity on sdb led3 : blink on activity on sdc
If I am reading your code correctly, it looks that only one LED can be configured for a block device. Is this true? If so, then the above configuration cannot be set.
You're correct that it's not possible with the current code. Multiple devices can be associated to with a single LED, but there's not currently a way to drive more than 1 LED from a single device. This is something that could be changed.
Also you are blinking the LED on any request to the block device. I would rather expect to be able to set the LED to blink on read and on write. (And possibly on other functions, like discard, or critical temperature, or error, ...) I would like to know what other people think about this.
I wanted to keep things as simple as possible for now. I don't think that there's any particular reason that separated LEDs couldn't be configured for read and write requests. (It looks like it should be pretty easy to distinguish reads vs writes in a struct request.) My feeling is that things like temperature, errors, etc. are better monitored from user space, as they tend to require actively querying the drive. Like you, I'm interested in knowing if there is actually hardware out there that has separate read/write LEDs. All in all, I feel like I should be able to implement almost everything that you've suggested, *if* I can figure out the block device lookup issue, but I really don't have any ideas on that. Thanks for your patience and feedback! -- ======================================================================== In Soviet Russia, Google searches you! ========================================================================