Messages in this thread | | | Date | Mon, 3 May 2021 13:56:15 -0300 | From | Enzo Matsumiya <> | Subject | Re: [RFC PATCH 2/2] leds: trigger: implement block trigger |
| |
On 05/03, Pavel Machek wrote: >> As already commented on, this for_each_blk() construct is not a good idea. >> Infact, I guess it would be better if you could invert the logic: >> Not having the block trigger enumerating all devices, but rather let the >> devices register with the block trigger. >> That would have the benefit that one could choose which block device should >> be handled by the LED trigger subsystem, _and_ you would avoid the need for >> a for_each_blk() construct. >> Thing is, I don't think that all block devices should be handled by the LED >> trigger; eg for things like 'loop' or 'ramdisk' it is very >> >questionable. > >> Downside is that you would need to modify the drivers, but realistically >> there are only very few drivers which should be modified; I would go for >> nvme-pci and the sd driver for starters. Maybe floppy, but arguably that can >> omitted as one has a very good audio indicator for floppy accesses >> :-) > >And we already have disk activity trigger. Maybe NVMe and SD needs to >be modified to use it? > >Best regards, > Pavel
TBH I haven't thought of that. My initial idea was to actually offer maximum flexibility to the user, so exposing all block devices on the system [*], being able to set any LED available as an indicator for each of those.
But, indeed, just using ledtrig-disk in NVMe and SD might just be simpler.
[*] - again, I see now this was a bad idea and will be changed in a possible next version
| |