Hi! > > - if the device supports only one hardware controlled mode, it is > > put into this mode > > - if the device supports several hardware controlled modes, it is > > put into one of these modes and a hardware_trigger file is > > created, via which these mode can be changed. > > This hardware_trigger file behaves similarly to classic trigger > > file, ie. on read it returns space-separated list of supported > > hardware triggers, the currently selected one in brackets. > > We already have had a report of trigger list exceeding PAGE_SIZE in case > of a system with huge amount of cpus (dedicated cpuN trigger created for > each cpu). Effectively, sooner or later we will need to fix this > interface. > > It is better not to get exposed to this risk anymore. > > Instead of space separated list I propose a directory with > files named after trigger names. The files will accept/print > 1/0 values signifying whether the trigger is enabled/disabled. Lets say we are over PAGE_SIZE with cpuX triggers. (Those should be really be made one cpu trigger with parameters, but...) That means we have something like 700 triggers. Lets say we have 20 LEDs in the system (my thinkpad has 19). That would be 700*19 == 13300 files in sysfs. I assume that would be something like 4MB of kernel memory... I believe better solution would be to lift PAGE_SIZE limit from trigger list... Hmm. Or maybe simply list cpu0 (but not cpu1, cpu2) in the triggers file, but still accept that as a parameter? :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
