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