The kernel config parameter `DRM_AMD_DC_DCN3_0` is required to enable
the RX 6000 series GPUs, and is supported on kernels at least `5.9.12`.
Source: https://wiki.gentoo.org/wiki/AMDGPU#Installation
Starting from Linx 5.6, there is partial upstream support for the Multipath TCP
protocol. There are no downsides to enabling it afaict, since
applications need to opt-in when creating a socket.
From https://github.com/multipath-tcp/mptcp_net-next/wiki:
"[...] users of regular TCP continue to get the same type of connection and
performance unless MPTCP is requested."
As per the in-line comment, this is where distros should configure it.
Not via kernel command line parameters.
As found by looking at the implementation, while exploring the cause of
a bug on the Raspberry Pi 4, it was found that `cma=` on the command
line parameters will overwrite the values a device tree will have
configured for a given platform.
With this, the more recent 5.4 vendor kernel boots just fine on the
Raspberry Pi 4 using our common configuration.
Without this, the kernel would generate a random one for us which obviously
isn't reproducible.
`nix-build -A linux --check` succeeds now!
(Tested at different times with different kernel)
We currently build CONFIG_IPV6=m.
This seems to be not really well-supported in mainline kernels - see
https://lore.kernel.org/netdev/20201115224509.2020651-1-flokli@flokli.de/T/#u
Compiling it as a module doesn't give too much benefit - even for people
who did explicitly set `enableIPv6` to false, the `ipv6` module was
still loaded, as soon as another module was loaded that requires it
(bridge,br_netfilter,wireguard,ip6table_mangle,sctp,…).
By compiling it in, we only loose the possibility to not add it to
`boot.kernelModules` anymore (as it's part of the kernel directly). The
space savings are negligible.
People wanting to disable IPv6 still get the appropriate sysctls and
options set (while having the kernel code loaded), nothing is really
changing here.
This config value ensures that when booting through e.g. UEFI, the
existing framebuffer contents stay put until the first character is
printed. As the default NixOS stage-1 immediately outputs a welcome
message on init, this does not impact it, but it will allow for a cleaner boot when
configured as such.
