Hi!
My mentionable reasons for a custom kernel are optimizations for audio
work (CONFIG_HZ=1000 and "Preemptible Kernel (Low-Latency Desktop)"),
the specific CPU and reducing time and energy costs of building by
selecting only the necessary drivers.
I added the package definition to my system configuration to then have
the kernel build and put into place via `guix system reconfigure
/ect/config.scm`. This failed several times after building, when guix
does what I understand to be an initramfs test run, where it tries to
load a bunch of modules.
With the help of #guix, I found a list that appears in
linux-modules-builder and init-builder:
("ahci" "usb-storage" "uas" "usbhid" "hid-generic" "hid-apple"
"dm-crypt" "xts" "serpent_generic" "wp512" "nls_iso8859-1" "pata_acpi"
"pata_atiixp" "isci" "virtio_pci" "virtio_balloon" "virtio_blk"
"virtio_net" "virtio_console")
Aside of the issue of requiring hid-apple on a desktop PC, and lots of
crypto where no encrypted partition is in sight, it would be nice if an
error could be triggered before the entire kernel and drivers are build.
My notes from hunting down these configuration dependencies:
ahci
dm-crypt, depends on:
Multiple device driver support: Device mapper support: Crypt target
support
Cryptographic API: User-space interface for hash algorithms
User-space interface for symmetric key cipher
algorithms
RIPEMD-160 digest algorithm
SHA384 and SHA512 digest algorithms
wp512 / Whirlpool digest algorithms
LRW support
serpent_generic / Serpent cipher algorithm
Twofish cipher algorithm
Device Drivers: Block Devices: Loopback device support
File systems: FUSE (Filesystem in Userspace) support
hid-generic
hid-apple
isci
nls_iso8859-1
pata_acpi
pata_atiixp
uas, CONFIG_USB_UAS in Device Drivers, USB, USB Attached SCSI.
usb-storage
usbhid
virtio_pci
virtio_balloon
virtio_blk
virtio_net
virtio_console
xts
Things were going well until I got to XTS support. With either my custom
configuration, or a default one, XTS is stuck on -*-, i.e. mandatory
built-in. The after-build phase will fail if there's no xts.ko module!
I tried to figure out the dependencies and failed. Finally, I took the
guix kernel configuration, replaced the entire segment device-drivers up
to file-systems with one from my custom version and did the few other
changes. It works!
Now if anyone knows or can figure out how *exactly* to turn XTS's -*-
into a {M}, that would still be good to know. A script that turns any
kernel configuration into a guix-sd-safe one, or changes to make these
gymnastics unnecessary would be great!
A drawback of a lean and specific kernel is of course that it won't work
with drastically changed hardware. A situation once can suddenly be
forced into on hardware failure.
Kernel variants are tied to system generations, right? What do I have to
do if I want a choice between 2 kernels independent of generations?
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/