With this disabled, cameras would not get a `/dev/mediaX` entry matching
the `/dev/videoX` which broke any application (e.g: `uvcdynctrl -l`,
`media-ctl -p`) depending on this interface.
Since we don't have a split debug info output yet, don't waste time
writing several gigabytes of debug info that's all going to be stripped
out at the end.
This change only affects Aarch64 (where some joker has enabled it in the
architecture defconfig) and is a no-op on the others.
There is no maintainer for this package, probably not many users.
It requires effort to fix all third-party modules for this old kernel
versions. It might contain unpatched security holes.
For Pixel chromebooks, we have the samus-kernel.
Apart from that https://github.com/GalliumOS/linux might be a good choice.
There's an upstream build failure on ARM (not directly related to Xen
but rather some other config options it enables). The xen package is
x86_64-only anyways.
Linux 4.9 includes experimental amdgpu support for AMD Southern Islands
chipsets. (By default, only Sea Islands and newer chipsets are supported.)
Southern Islands chips will still use radeon by default, but daring users may
set `services.xserver.videoDrivers = [ "amdgpu" ];` to try the experimental
driver.
The plan is to fix mounting DFS shares on NixOS (for which some of these
options are needed), but I figured it might be a good idea to enable all
CONFIG_CIFS_* like Fedora 24 and Ubuntu 16.04 while at it. Ubuntu even
has CONFIG_CIFS_SMB311, but as Fedora do not, I left it out.
Mounting DFS shares still doesn't work; need to configure cifs.upcall
and /etc/request-key.conf. Until then, using GVFS as a workaround.
Enable encryption support for both F2FS and ext4. For ext4 this is a bit
tricky, since pre-4.8 the way to enable it as a module was just
"EXT4_ENCRYPTION=m" but after that it changed to "FS_ENCRYPTION=m &&
EXT4_ENCRYPTION=y".
Also make sure UDF is enabled.
The Yama Linux Security Module restricts the use of ptrace so that
processes cannot ptrace processes that are not their children. This
prevents attackers from compromising one user-level processes and
snooping on the memory and runtime state of other processes owned
by the same user.
