On 8/19/19 8:22 PM, Jacek Anaszewski wrote: > 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. I must withdraw this statement. This is not similar to usbport trigger. The difference is that with ledtrig-block we have separate triggers per each device and I am not aware if there is some centralized mechanism similar to blocking_notifier_chain (usb_notifier_list in drivers/usb/core/notify.c) available for block devices, that would allow to gather all available block devs under common trigger. Moreover I remember Greg once discouraged using notifier chains as they are unsafe, so we would need some other solution anyway. >>> 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
