LWN: Comments on "A different approach to kernel configuration"

A different approach to kernel configuration

csigler — Fri, 15 Sep 2017 03:44:34 +0000

This just shows how old we both are... :-(

A different approach to kernel configuration

flussence — Thu, 14 Sep 2017 19:05:27 +0000

Graphics drivers are particularly annoying here. You either want everything for a distro kernel, or want a very specific one for a custom kernel. But unlike (say) sound cards, the latter's not an option — you need to compile in support for all nVidia cards or all Radeons or all Intel chips. My /boot/vmlinuz is growing almost a megabyte per year because of it.

A different approach to kernel configuration

smitty_one_each — Thu, 14 Sep 2017 11:43:52 +0000

> As a bonus, this kernel boots in 1/5 of the time.

Time being frog$kins, a more rapidly available cloud image is a right jolly awesome thing.

A different approach to kernel configuration

edgewood — Thu, 14 Sep 2017 04:00:44 +0000

I had the exact same thought when I first read the article. I was surprised there wasn't a reference to Aunt Tilly in it!

A different approach to kernel configuration

csigler — Thu, 14 Sep 2017 03:20:22 +0000

> ... the config subsystem has grown so large that it's gotten out of control.

Paging ESR... paging Mr. ESR.... ;-)

A different approach to kernel configuration

montj2 — Wed, 13 Sep 2017 23:24:24 +0000

I could not find a definitive answer, but I am left to believe it is something private for his current position at the National Security Research Institute of South Korea. Were you able to find more?

A different approach to kernel configuration

Yui — Wed, 13 Sep 2017 23:16:18 +0000

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

A different approach to kernel configuration

Tara_Li — Wed, 13 Sep 2017 18:40:27 +0000

Perhaps if the tool scanned the hardware first, and then generated a "suggested config" that could then be tweaked - bonus points if it includes comments on what it found and why it suggested that configuration - and even a "Found nVidia graphics chipset - would you like to use the free nouveau driver, or will you be installing the nVidia proprietary driver later?"

A different approach to kernel configuration

edeloget — Wed, 13 Sep 2017 16:15:02 +0000

This is indeed an interesting approach but it's limited to a single use case - rebuilding a config for a kernel that suits you.

I would love to see someone try to tackle the need for a simpler configuration tool. Creating a booting kernel for an esoteric custom board is a hard task even for expert themselves, and its has to do with how the kernel config is organized (not how menuconfig works).

A different approach to kernel configuration

Frogging101 — Wed, 13 Sep 2017 15:10:52 +0000

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

unixbhaskar — Wed, 13 Sep 2017 04:31:15 +0000

I am looking forward to such a thing to come up. I have been hand-tuning kernel for many years now and it is a cumbersome process, but you gain a lot of insight about it. But having a tool like this would have certainly help lesser mortals better time.

A different approach to kernel configuration

pabs — Wed, 13 Sep 2017 03:23:45 +0000

Did Kang mention which distro he is working for?

A different approach to kernel configuration

Frogging101 — Wed, 13 Sep 2017 03:15:27 +0000

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

rodgerd — Tue, 12 Sep 2017 21:35:00 +0000

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

A different approach to kernel configuration

marduk — Tue, 12 Sep 2017 16:45:25 +0000

I'm really looking forward to using a tool like this. I have been hand-tuning kernels for years but there's always something in the back of your head that makes you wonder if you really needed option A or if you left out option B which you could have really benefited from. It's true that the config subsystem has grown so large that it's gotten out of control. It's going to require an overhaul and a fresh set of eyes to really make it into something impressive. But like the article states there is little demand upstream, or downstream for that matter.

A different approach to kernel configuration

tao — Tue, 12 Sep 2017 12:46:16 +0000

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

WolfWings — Tue, 12 Sep 2017 12:26:31 +0000

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.