Switch to kernel.stdenv.mkDerivation for package

[umbrageodotus]

Allows for LLVM-specific kernel module arguments to be used if the kernel uses LLVM.

[umbrageodotus]

Please turn this into a single commit. Also, if there's a better way (like DEFAULTING to the kernel's stdenv but allowing modifications), let me know.

[AndyFilter]

Looks good to me, thought I like how there are more commits than lines changed 😄.

I can't test this PR, so I'll need to wait for someone with Nix to make sure these changes are fine.

[umbrageodotus]

@AndyFilter i use the commit and it works for cachyos (llvm)

[AndyFilter]

Hey, @kitten. Sorry to disturb You, but could You please take a look at this PR and make sure it runs properly when You have a moment.
I don't have NixOS and can't test this out. I tried asking some clanker for a review, and this is what I got:

• In the before state, stdenv is used throughout the file for derivation and build inputs. This has been replaced with kernel.stdenv after the change. The impact of this substitution is substantial as it relies on kernel-specific stdenv, which could affect the broader behavior of the derivation or introduce unintentional restrictions. Consider whether this substitution unnecessarily narrows compatibility or was genuinely intended.

• The variable stdenv is removed from pkgs inputs in line 2 of the modified version of the file. This removal is inconsistent with the prior usage of stdenv.mkDerivation unless substituted adequately.

Please understand @umbrageodotus, I have nothing against You, or Your code. I simply want to double check everything to make sure it works before merging. I do the same for my own PRs, I wouldn't merge my own PR without someone checking it (for the most part) (I don't trust myself that much, haha).

[umbrageodotus]

Yep, don't worry!

[kitten]

Sorry, been a little too busy and haven't used my NixOS system in a while. I can try to test this out but wanted to note that in #66 I let a comment for kernelModuleMakeFlags for that LLVM build.

kernelModuleMakeFlags is unoverridden in this PR, and I'm assuming that will also need to be swapped out. It stands to reason that the only necessary change would be to remove kernelModuleMakeFlags and to use kernel.commonMakeFlags instead. This might be enough to do the trick (?)

#66 (comment)

[umbrageodotus]

Why common make flags? I overwrote kernel make flags too, though. It's always the ones provided by the kernel.

[kitten]

I'll probably have time this week to look at it now that I've updated my NixOS machine, which I wasn't running for a hot minute.

It doesn't likely matter too much how the make flags are sourced, although the "base" flags by convention are on the commonMakeFlags property and I'm not aware of alternatives.

What matters is that the custom flags set in the derivation are defaulted to the latest kernel's flags, not the custom kernel we're building the module for. Hence, if it's not using GCC that just won't work. That's mostly just how I wrote that argument default, since I was assuming the latest kernel's make flags would always work

[umbrageodotus]

No, I believe I overwrote them on a PR I made on another account. I'll show it asap.

[umbrageodotus]

No, I believe I overwrote them on a PR I made on another account. I'll show it asap.