Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
thinkpads: refactorings + modularization + some new options #101
What you think about this? I'm now using those options as:
- convert `common/cpu/intel` and `common/pc/laptop/acpi_call` to proper modules. This allows a) descriptions and b) enable/disable instead of `import` - enable both for thinkpad by default. Disable explicitly in specific profiles (for example, AMD ThinkPads don't need those). This is mostly to remove repetitions and make a "generic" ThinkPad config (I have E470 but none of profiles matches my needs). - add `hardware.cpu.intel.max-frequency` option, which allows reducing CPU performance (a bit duplicates powerManagement.cpufreq.max but it's a separate mechanism). Perhaps should eventually move to nixpkgs? - add `hardware.battery.powersave`, which enables some non-controversial power saving services. Disabled by default. - add `hardware.battery.optimize`, which documents nuances of battery lifetime. Basically, ressurects deleted in #100 code but disabled by default. - convert a comment about fprintd into an option `hardware.fingerprint.enable`, with description What you think about this? I'm now using those options as: ``` imports = [ <nixos-hardware/lenovo/thinkpad> ]; hardware.battery.powersave = true; hardware.battery.optimize = "mostly-pluggedin"; hardware.fingerprint.enable = true; # increase nixos-rebuild time from 4.3s to 4.7s hardware.cpu.intel.max-frequency = 90; ```
yegortimoshenko left a comment •
I don't think this repo is appropriate place for modules :-( It's oriented towards set-and-forget whole-system hardware profiles, with no opinionated config options, which differentiates it from
We can create
Also, semantically, CPU choice is a tristate, not a boolean: there's no reason why generic ThinkPad would be Intel-specific, with AMD being an override (there are both Intel and AMD ThinkPads).
Overall, I think this is out of scope.
@yegortimoshenko ok, let's discuss some points. I want a to provide constructive arguments in my defense.
there are many devices in thinkpad family. Let's add profiles only for buggy ones. Lenovo Z510 and Thinkpad T430s are good examples of profiles, which fix real problems with hardware.
OTOH, T440s and T440p are bad examples, in that they enable
But if we add
I agree with latter, we want workaround model-specific problems later. But I don't see how making separate profile helps here. Instead we can do some runtime checks in "generic" model to apply fixes. In theory, we can also add an option:
and require user to set correct model (
Dunno. I'm not very fond of intel/Thinkpad specific workarounds in NixOS. Also, it's easier to define options here, in-place, than define them in
It indeed is, only newer thinkpads support it. Though it is a must-have for TLP to work properly. 6 profiles had imported it explicitly. T430, T440p, T460s, X1, X250, X270 supports it, but didn't enable. Was that a bug or a feature? Nobody knows. I can only assume it was a bug. In that case 12 profiles need
If we never merge this, then potential users of NixOS on X1 can never find out that their TLP settings don't work properly. Or, worse, they can fix stuff themselves and not upstream here.
the only opinionated settings are
There is room for improvements here.
I wanted battery powersaving recommendations since this repo was introduced. So I'd like such "recommendations" to be part of this repo.
@danbst Thanks for doing this, I think this repo can be the right place to condense "sane/good defaults". The answer to your question is:
Linux kernel policy is to use inputs from all available devices, including black box TPM instructions/modules like those on Intel chips (source, sorry it's inflammatory but it's the only one I could find).
Meaning, it's not really possible to control
Again, this is better suited for Nixpkgs. Fundamentally, the only reason people use this repo at all is so that they don't have to set up hardware themselves (we set up everything there is on the motherboard).
By the way, this is a solvable problem, NixOS module system can support exclusions without a major rewrite. As a temporary workaround, there are various
User-defined enums are bad idea: there are quite a few ways to write down the same model. And no one will set it post-hoc, while we should be able to push quirk fixes to devices that might have previously not required any. We enforce leaf profiles so that we can dispatch workarounds based on specific model of the device.
Literal runtime checks are the goal: much of what is not specific to a certain model can and should migrate to
It's fundamentally unknowable which ones are, or will be buggy. It depends on kernel version: devices do break over time. Case in point,
It's debatable whether this is a good idea (there is a huge lot of ThinkPads in the wild that do not support
I really think that Lenovo default (96-100%) could go into
Malicious inputs shouldn't be a problem as long as the PRNG is seeded with enough entropy from a secure source. As tpm is not the only source this isn't an issue.
Bad inputs can't hurt the security as long as the PRNG isn't broken. And users can input data to /dev/urandom anyways, so disabling the tpm wouldn't prevent an attack anyways.
A good summary of this is https://www.2uo.de/myths-about-urandom/
I'd like to know details here.
Also, it is an open question if 6 profiles I've listed above are incomplete. Hardware supports
BTW, it may be a good idea to teach
returns enough information to use then in this repo
We can go even further and detect CPU model in