Which seems much less error-prone. I’m not very familiar with kernelParams, what the range of possible values is, or what it does under the hood, which is why I’m asking first if this makes any sense at all.
Another (not mutually exclusive) measure to make kernelParams less error-prone would be to run some kind of verifier on the grub config before reboot. I couldn’t find such a tool from a quick search online, but if that’s possible it would be great to do at build time, because once you reboot and grub is dead, you can’t even rollback.
I think the problem would be the sheer volume of potential options. See the kernel docs for a massive, non-exhaustive list.
These are also as ever-changing as the kernel, depend on which modules you happen to compile into it and additional ones are introduced by the also fast-moving systemd.
Using an array makes explicit to the user that there is no exhaustive set in nixpkgs, and that they are neither validated nor smartly concatenated. It’s just args as with cli args.
I would be impressed with a PR that manages to encapsulate this well, even more so if it managed to do valiation
Well we could do what we often do in these cases, which is to nixify the most commonly used ones and provide an escape hatch so you can specify arbitrary ones the same way we do now