de-vendorify kernel config (build full NixOS kernel)#341
Conversation
|
If we drop that all the way down to these (which are necessary to get the difference with yours is ( My take on these, from the perspective of whether the "simple" config needs changing:
|
|
@dramforever what is this "simple" config you are talking about, where can I find it? Can you perhaps make a specific suggestion using the diff feature in github? |
|
Ah, you dropped all options from the extraStructuredConfig except those two and then diffed the generated config, meaning all other statements are no-ops? I would think we also need I also don't understand how HID_APPLE can be "y" when not specified, since it can be built as a module the generate-config.pl would always opt for that. |
|
|
|
Oh, missed this: I actually don't know why |
yuyuyureka
force-pushed
the
minimize-patches
branch
2 times, most recently
from
fffc941 to
33935ed
Compare
|
Removed redundant config (and some more; I think DRM_SCHED-related things are also differing, but it seems to work fine with the simple version on my machine). Also attempted integrating it into the CI. |
yuyuyureka
force-pushed
the
minimize-patches
branch
from
f05c9cd to
7100554
Compare
|
Looks like the CI build is working, thanks for the experiment. I will test it more thoroughly later. We should definitely not be building for x86-64 though, although I guess that's neat that it worked. |
yuyuyureka
force-pushed
the
minimize-patches
branch
3 times, most recently
from
1d34925 to
d157365
Compare
|
From what I can tell we're not building for x86_64, but just on x86_64, which is good since it will cache the derivation for cross-compilation users. |
|
I just built this with the latest nixpkgs and have a few issues:
|
Yes, this is a known issue worked around in #343 and should be fixed for properly in NixOS/nixpkgs#436245
This is expected for boot.kernelParams = [ "hid_apple.swap_fn_leftctrl=1" ]; |
yuyuyureka
force-pushed
the
minimize-patches
branch
from
d157365 to
6fe465b
Compare
|
Ohh I guess that's a reason to keep HID_APPLE=m... I just rebased, so the Rust workaround should be included now |
yuyuyureka
force-pushed
the
minimize-patches
branch
2 times, most recently
from
94b36d1 to
2f642f7
Compare
|
We talked about this in the matrix chat, but I will summarize my results testing the latest version of this PR here for transparency:
|
|
i fixed the audio issue by building some things as modules, see my branch. |
yuyuyureka
force-pushed
the
minimize-patches
branch
from
14b6886 to
60ad4a8
Compare
|
I think what's still missing here is a somewhat trustworthy binary cache & CI. At the moment, I am not convinced I would want to build even the installer images in the nix-community CI which builds derivations from untrusted PRs. |
Thanks Walter! I squashed your commits together and added them to my branch. |
yuyuyureka
force-pushed
the
minimize-patches
branch
2 times, most recently
from
6d67867 to
a5ee443
Compare
yuyuyureka
force-pushed
the
minimize-patches
branch
from
a5ee443 to
2f6bbcb
Compare
ghost
mentioned this pull request
|
Any update on this? I would really like to see this merged. |
|
This kernel takes 2-3 hours to compile on my M2 air, compared to around 20 minutes for the minimal one, so I think that a community cache is necessary before it can be merged. Otherwise, the kernel works fine (I have been using it). |
Upstreaming m1n1 and other components to nixpkgs would be nice and is a worthy effort, but they barely add any compile time so I don't think that they should be considered a blocker for moving the vender-specific kernel build to a binary cache. Maybe someone involved in the nix-community infra could tell us if there is anything blocking that. |
|
The last status here was that we (the nixos-apple-silicon maintainers, but mostly me) were not ok with the idea of encouraging people to use the kernels and install images built on the same CI which also builds arbitrary untrusted derivations (PRs on other nix-community projects). |
|
I've just checked this out in my personal fork and I'm happy to report that it completely resolves whatever was causing #294! So I would hope that once this is merged, there might be fewer reports of issues with hardware-accelerated Wayland compositors like Niri and Hyprland... what exactly the "fix" was, I have no idea. |
|
Some nits, remove unused arguments and also this change means we aren't really tracking the asahi-wip tree or basing off of fedora releases. diff --git a/apple-silicon-support/packages/linux-asahi/default.nix b/apple-silicon-support/packages/linux-asahi/default.nix
index 397edf8..a0a5552 100644
--- a/apple-silicon-support/packages/linux-asahi/default.nix
+++ b/apple-silicon-support/packages/linux-asahi/default.nix
@@ -11,10 +11,9 @@ let
stdenv,
lib,
fetchFromGitHub,
- fetchpatch,
buildLinux,
...
- }@args:
+ }:
buildLinux rec {
inherit stdenv lib;
@@ -23,7 +22,6 @@ let
extraMeta.branch = "6.16";
src = fetchFromGitHub {
- # tracking: https://github.com/AsahiLinux/linux/tree/asahi-wip (w/ fedora verification)
owner = "AsahiLinux";
repo = "linux";
tag = "asahi-6.16.5-2";
@@ -65,11 +63,6 @@ let
++ _kernelPatches;
};
- linux-asahi = (callPackage linux-asahi-pkg { }).overrideAttrs (_: {
- # FIXME: Remove when https://github.com/NixOS/nixpkgs/pull/436245 lands
- preConfigure = ''
- export RUST_LIB_SRC KRUSTFLAGS
- '';
- });
+ linux-asahi = (callPackage linux-asahi-pkg { });
in
lib.recurseIntoAttrs (linuxPackagesFor linux-asahi)
The last change requires a flake update since it was merged on Aug 23rd and the nixpkgs in n-a-s is from Aug 19th. |
yuyuyureka
force-pushed
the
minimize-patches
branch
3 times, most recently
from
02faa63 to
358f408
Compare
Credit to zzywysm for this solution. According to James Calligeros (chadmed), this is most likely necessary because of some race condition.
yuyuyureka
force-pushed
the
minimize-patches
branch
from
358f408 to
c814c5d
Compare
ghost
mentioned this pull request
6 participants
I've been running this (NixOS-derived) kernel config for many months.
The downside is it takes a few times longer to build, since it compiles all possible modules. But this should no longer be a problem now that we have a CI and binary cache.