INITRD vs MODULES FROM DISK vs HUGE

yes

I use generic with initrd. That way I can modify the initrd to reflect my luks setup.

Trying to add some value to this thread...

On, slackware I use Pat's 'generic' kernel with
MODULE_LIST="ext4:xhci-pci:xhci-hcd:usbhid:hid-generic" for the initrd.

When I build my custom kernels, which I use on CRUX, I configure those 5 as kernel built-ins, and have no modules in the initrd. Because there are no modules in the initrd, it is not version specific and doesn't need updating all that often. On a kernel update, I only have to copy the bzImage file into the elilo subdirectory of /boot/efi/EFI/

I guess the question is: if we did away with the generic/huge split and only had one kernel, what modules would people need built into 'generic' for people to be able to use it in place of 'huge'.

These 5 (and their unspecified dependencies) would do it for me.

3 members found this post helpful.

I compared memory usage between kernel-generic-5.12.11-x86_64-1 + initrd and kernel-huge-5.12.11-x86_64-1. The initrd was made by 'mkinitrd -m ext4'. The difference in available total memory was 9636 KiB.

I use custom kernel, all drivers built-in, with initrd

Just add the intel microcode in my mkinitrd.conf :

Back in the day, that was a big chunk of memory.
Now its 0.009190 GiB.

Regardless of my preferences, I'm glad there's both huge and generic kernels, so that we aren't all locked into one thing or the other. (Keeping with the Slackware philosophy that it shouldn't stand in the way of what you need.)

1 members found this post helpful.

Since kernel modules go so far back into historical gear I know far more about what I don't need support for than what I do. This is mildly complicated by interactive modules that essentially have dependencies of their own. So I go the opposite direction. I pare down Huge and only hard code some of what I'm certain I need or desperately want like ext4 and specific CPU support along with realtime low latency. I very much dislike initrd which is only really required for encrypted systems that boot.