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! ========================================================================