F5F Stay Refreshed Software Operating Systems Linux kernels running on modern desktops and laptops

Linux kernels running on modern desktops and laptops

Linux kernels running on modern desktops and laptops

T
Taybaybay
Posting Freak
850
03-01-2016, 06:09 PM
#1
It's a kind of a ritual, maybe a kind of a relic? When I get a new notebook, I start a fresh kernel .config and try to get all needed modules compiled-in. After some iterations, only some hardly ever used modules (like xfs support) are left and I'm happy. At times, this provided faster boot times didn't need an initrd at all. But is there still a point of a static kernel - on nowadays's laptop/desktop systems? For some years now, I keep Intel nic drivers as modules for proper unloading and power saving. Mute and speaker LEDs only seem to work with ALSA compiled as a module (had to introduce initrd lines in my grub config on Thinkpads ~10y ago). initrd is now needed to contain all kinds of microcode and binary firmware.initramfs-tools are easy to work with and it doesn't make the system faster. Security was an issue. Until modules could be signed, it was easier to keep track of a single file. ... and they are not experimental any more, practically all distros use modules heavily, even for ata and rootfs filesystems. There's still a point in disabling debug functions and symbols, that distros keep on despite vanilla's recommendations. Smaller kernel and smaller initrd boot faster. Re-building the kernel with cflags for the actual machine and its architecture doesn't depend on modules. There's still headroom against distros. It might be beneficial to disable certain drivers (mei*, cpuid, egpu drivers of iommu devices), still, a simple blacklist is more flexible than recompiling. Another benefit was, that I only had to handle one file to backup my kernel. This was useful for building with "make bzimage", now there's "make bindeb-pkg" and "make binrpm-pkg" for a manageable package. So, is there anything left in the "pro static kernel" corner, that's valid today? Any problem with modules that isn't solved (for desktops/laptops)?
T
Taybaybay
03-01-2016, 06:09 PM #1

It's a kind of a ritual, maybe a kind of a relic? When I get a new notebook, I start a fresh kernel .config and try to get all needed modules compiled-in. After some iterations, only some hardly ever used modules (like xfs support) are left and I'm happy. At times, this provided faster boot times didn't need an initrd at all. But is there still a point of a static kernel - on nowadays's laptop/desktop systems? For some years now, I keep Intel nic drivers as modules for proper unloading and power saving. Mute and speaker LEDs only seem to work with ALSA compiled as a module (had to introduce initrd lines in my grub config on Thinkpads ~10y ago). initrd is now needed to contain all kinds of microcode and binary firmware.initramfs-tools are easy to work with and it doesn't make the system faster. Security was an issue. Until modules could be signed, it was easier to keep track of a single file. ... and they are not experimental any more, practically all distros use modules heavily, even for ata and rootfs filesystems. There's still a point in disabling debug functions and symbols, that distros keep on despite vanilla's recommendations. Smaller kernel and smaller initrd boot faster. Re-building the kernel with cflags for the actual machine and its architecture doesn't depend on modules. There's still headroom against distros. It might be beneficial to disable certain drivers (mei*, cpuid, egpu drivers of iommu devices), still, a simple blacklist is more flexible than recompiling. Another benefit was, that I only had to handle one file to backup my kernel. This was useful for building with "make bzimage", now there's "make bindeb-pkg" and "make binrpm-pkg" for a manageable package. So, is there anything left in the "pro static kernel" corner, that's valid today? Any problem with modules that isn't solved (for desktops/laptops)?

B
blackceaser
Member
119
03-15-2016, 12:46 PM
#2
Most users stick with the built-in kernel for their preferred distribution. For devices with limited processing power and no update requirements, creating a static build might be more practical.
B
blackceaser
03-15-2016, 12:46 PM #2

Most users stick with the built-in kernel for their preferred distribution. For devices with limited processing power and no update requirements, creating a static build might be more practical.

S
SkyWarsPro___
Member
200
03-16-2016, 03:29 PM
#3
Are there any requirements for embedded devices to boot within a half-millisecond? By 2020, most likely SSDs were common.
S
SkyWarsPro___
03-16-2016, 03:29 PM #3

Are there any requirements for embedded devices to boot within a half-millisecond? By 2020, most likely SSDs were common.

T
tomtiger99
Member
111
03-31-2016, 04:04 AM
#4
Only security measures are involved, some rootkits deploy their own components. If the kernel is static and lacks loadable module support, this scenario won't occur. It's frustrating being a Nivida user in that situation...
T
tomtiger99
03-31-2016, 04:04 AM #4

Only security measures are involved, some rootkits deploy their own components. If the kernel is static and lacks loadable module support, this scenario won't occur. It's frustrating being a Nivida user in that situation...