On 8/19/19 4:38 PM, Pavel Machek wrote: > On Sat 2019-08-17 22:07:43, Jacek Anaszewski wrote: >> On 8/17/19 4:55 PM, Pavel Machek wrote: >>> On Fri 2019-08-16 01:59:58, Akinobu Mita wrote: >>>> This allows LEDs to be controlled by block device activity. >>>> >>>> We already have ledtrig-disk (LED disk activity trigger), but the lower >>>> level disk drivers need to utilize ledtrig_disk_activity() to make the >>>> LED blink. >>>> >>>> The LED block device trigger doesn't require the lower level drivers to >>>> have any instrumentation. The activity is collected by polling the disk >>>> stats. >>>> >>>> Example: >>>> >>>> echo block-nvme0n1 > /sys/class/leds/diy/trigger >>> >>> Lets use one trigger "block" and have the device as a parameter, >>> please. >>> >>> We already have 1000 cpu triggers on 1000 cpu machines, and yes, its a >>> disaster we'll need to fix. Lets not repeat the same mistake here. >>> >>> I guess it may be slightly more work. Sorry about that. >> >> We should be able to list available block devices to set, >> so the problem would be not avoided anyway. > > Should we? We need to list triggers, but we may not list all the devices... This is similar to usbport trigger that lists available ports as files in a sub-directory. We might eventually go in this direction. >> And Greg already proposed >> a solution for trigger file PAGE_SIZE overflow, so this should not pose >> a big problem in the future once that is implemented. > > Which still leaves us with pretty big/ugly triggers file... and we do > not have the fix in the tree yet. Still, we have that interface and must keep it. It implies the fix will need to be applied anyway. -- Best regards, Jacek Anaszewski
