|
|
Subscribe / Log in / New account

A different approach to kernel configuration

A different approach to kernel configuration

Posted Sep 12, 2017 12:26 UTC (Tue) by WolfWings (subscriber, #56790)
Parent article: A different approach to kernel configuration

Honestly the largest obstacle to kernel configuration is the menuconfig tool hasn't kept up.

Some newer systems are arbitrary such as picking a compression or encryption algo at random as 'required' despite the actual code not requiring any single algo, just AT LEAST ONE algo existing from a large set.

Others are setup one-way (the USB <-> networking <-> wireless trifecta for example) for the requirements so if you don't disable things in the correct order you can't disable other things.

And there are numerous "top level items" that could be pushed down a level (or two!) to organize the tree structure in a more 'discoverable' way.

A lot of it is improved Kconfig's being needed IMHO; the existing actual tools are well thought out, but Kconfig's aren't reviewed anywhere near as much as the functional code I feel, so a LOT of really bad cruft and cargo-cult scripting has ended up in those over the years since the syntax seems entirely unique and unrelated to anything else.


to post comments

A different approach to kernel configuration

Posted Sep 12, 2017 12:46 UTC (Tue) by tao (subscriber, #17563) [Link] (4 responses)

Yeah, the config system is a nightmare, especially when new options are introduced--the choices of what to default to N or Y by default seems arbitrary at best. defconfig should probably default to a modern machine.

A different approach to kernel configuration

Posted Sep 12, 2017 21:35 UTC (Tue) by rodgerd (guest, #58896) [Link] (3 responses)

At this point the defconf would probably be most accurate as a Xen or KVM guest.

A different approach to kernel configuration

Posted Sep 13, 2017 3:15 UTC (Wed) by Frogging101 (guest, #113180) [Link] (2 responses)

They already have kvmconfig and xenconfig.

In my opinion, the defconf should enable the components that one could reasonably expect to find on an x86 desktop or server system, and disable the more exotic drivers that one would never find on such a system to reduce the number of unnecessary components in a build.

A different approach to kernel configuration

Posted Sep 13, 2017 15:10 UTC (Wed) by Frogging101 (guest, #113180) [Link]

Actually, I don't even care what the defconfig is. But a "generic x86 desktop" config would be nice. My current method to get a base config for my desktop is to download a Debian or Ubuntu kernel .deb and extract the config.

You can get said debs at https://packages.debian.org/unstable/kernel/linux-image-a... or http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D . Make an empty directory to extract it to, and run dpkg -x <deb file> <destination dir>. Look in boot/ under the destination for the config. Copy it to your kernel tree as .config. If it's an older config, run "yes '' | make oldconfig" before using it.

A different approach to kernel configuration

Posted Sep 13, 2017 23:16 UTC (Wed) by Yui (guest, #118557) [Link]

Or perhaps distro-specific minimal configurations like Linus proposed five years ago. This would at least make the job of people who are working on a distro based on an existing one a bit easier.

https://lkml.org/lkml/2012/7/13/369


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds