Custom kernel module woes

[Thorsten Wilms]

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/