makeModulesClosure: handle builtin modules better

[CrystalGamma]

Rewrite the closure computation and copying.

Motivation for this change

The previous code discarded entire dependency trees if the first entry in the dependency list compiled by modprobe --show-depends is a builtin and otherwise handled its output in a rather hackish way.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[xaverdh]

While at it, can we also handle module arguments properly (in the spirit of https://github.com/NixOS/nixpkgs/pull/66235/files)?
Currently they are detected as separate modules. It should amount to throwing away any additional input from the first whitespace in a module name (I hope kernel modules are not allowed to contain whitespace..).

[CrystalGamma]

@xaverdh should be just another dummy variable in the read command, so yes … I don't know how to make it emit arguments though, because I'm not aware of a module name that produces arguments …

[xaverdh]

@xaverdh should be just another dummy variable in the read command, so yes … I don't know how to make it emit arguments though, because I'm not aware of a module name that produces arguments …

Well if you set a module parameter in the kernel command line (e.g. via boot.kernelParams) that shows up in the modprobe output. E.g. something like boot.kernelParams = [ "i915.enable_psr=1" ] should reproduce the issue if you have intel hardware.

update: I can confirm that with your pr and an additional parameter to read my issue is fixed.
update2: To be more specific, the error to look for is something like modinfo: ERROR: Module alias enable_psr=1 not found.

[xaverdh]

Thanks! Works on my system = )
Can we get this reviewed somehow? Maybe abbradar wants to have a look at it (since he originally wrote those lines), or we could try marvin for setting the status of this pr.

[lheckemann]

@ofborg test boot

[lheckemann]

Overall LGTM, I'd consider my array suggestion optional. Since the tests have passed, I'm all for merging once the array thing has been addressed (even if it's with a "no" ;) )

[lheckemann]

Using an array could be nicer here, since it avoids word-splitting "fun":

closure=()
[…]
closure+=("$module")
[…]
for module in "${closure[@]}"; do […]

[CrystalGamma]

The reason I used a file here was because the while read loop seems to run in a subshell, so code afterwards can't use any variables that are set in the loop. I personally don't have experience with arrays in Bourne-based shells (I use fish where I can) but I would assume the same holds for them. Anyway, thanks for merging. :)

[lheckemann]

Aah, I see. Yeah, you can work around that by making what's piped into while run in the subshell instead, as in…

while read cmd module args ; do
  […]
done < <(modprobe --config no-config -d $kernel --set-version "$version" --show-depends "$module")

but that does make reading it a little more confusing. Alternatively:

exec 5< <(modprobe --config no-config -d $kernel --set-version "$version" --show-depends "$module")
while read -u 5 cmd module args ; do
  […]
done

but yeah I'd say leave it as is now :)

[xaverdh]

Thanks for finally making some progress on this!