not sure who started it => Outcome of one of the Berlin meetups ==> tomes of machines, where the hardware config was in multiple repos, It was expected that things are breaking with different nixos versions
Not easy to keep in sync with nixos channels
remove/add for different channels to make it work
Ideally, hardware-specific modules should only contain configuration that cannot be autodetected, e.g. no "enable Intel microcode" config. So quirks etc.
nixos-generate-config: decouple hardware detection from logic of what to do with the detection results. E.g. nixos-generate-config would generate a hardware-configuration.nix with lines like:
hardware.detected.dmi.system.productName = "XPS 13 9370";
hardware.detected.cpu.modelName = "Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz";
and then some default-included NixOS module can implement some policies based on the CPU type (like enabling microcode).
Run nixos-generate-config automatically during nixos-rebuild? In case of hermetic/immutable config, print a warning if the new config is different?
- How does nixos-generate-config work?
- What will we add to nixpkgs hardware profiles and what not?
- Does it need binaries, and can they be produced? (mainly churn concerns through hydra)
- Maintainers/testers for Q/A
- Policies for removing/adding modules
- Documentation on how to use hardware profiles
- Usecases/user stories we are trying to solve
- How will first nixos-rebuild (with hardware detection) look like aka migration?
- How would we test different setups in time for a release?
- What is the timeline of implementing this? Turning on the hardware detection by default, integrating the modules into nixpkgs?
- Interface:
<nixpkgs/nixos/profiles/...>or totally through "facts" inhardware.detected. - How are we making this discoverable? Documentation for each hardware module. Metadata if needed.
"hardware survey" from the detected information (totally opt-in).