Add ability to override or stop tweaks locally. #14
Conversation
This is needed to prepare for some sort of user-local override mechanic - we need to be able to go through the list and avoid writing user-specified entries. The easiest way is to have the data available as a simple list we can iterate through in memory so that we can skip items. This should be easy enough to edit & compile as before.
This still tunes queue sizes.
`<disk>` was a suggestion to implement glob filtering to omit loopback devices. We know disks are sd*, mmc* and nvme*, so, let's start with those for now. Unfortunately glob() doesn't appear to have a negative match filter.
This will make various patterns easier to maintain.
Introduces "/etc/clr-power-tweaks.conf" which allows to prevent default tweaks from being written and/or add new custom tweaks. The custom tweaks are applied before the builtin ones. Either nothing is written to a match or file, and the file is added to the exclude list, or the value listed is written to the globbed files and it is added to the exclude list.
| string_exclude(match); | ||
| }; | ||
| if (ret == 2) { | ||
| write_string_to_files(match, value); |
There was a problem hiding this comment.
Do we need the feature to add more things? That's what tmpfiles.d is for, which is what this was before.
There was a problem hiding this comment.
I don't feel it's too horrible to have all of these in a single and logical place. It also could have gone into sysctl for the most part, or better, we'd patch the kernel defaults. But all of those risk that it becomes overly complex to sort out power related problems where "something is not tuned right" but there are 20 places it could be.
Having it here also allows us to "just disable clr-power-tweaks" as an initial problem solving step...
I want to avoid writing several times into things that touch hardware. I also want to have a mechanism to disable the program from touching some files at all, and this seemed the simplest approach, and covers both desired features. |
These pages are stubs for now. This is just the build structure for them.
Includes several minor bugfixes/cleanups. It's reasonably well split out.