Recent Features
| |||||||||||||
Kernel configuration for distributionsKernel configuration for distributionsPosted Jul 19, 2012 2:28 UTC (Thu) by pr1268 (subscriber, #24648)Parent article: Kernel configuration for distributions
I thought the various distros did this already. Not just in the config file, but mostly through the addition of downstream code to make the kernel work for that particular distro (like the various security modules as mentioned in the article). At least that's been my experience with Fedora. The one time I tried compiling a vanilla kernel on Fedora (way back in FC2 or 3 or so), it was a configuration nightmare and a boot time disaster. Same with SuSE 9.{0,1}.
(Log in to post comments)
Kernel configuration for distributions Posted Jul 19, 2012 3:43 UTC (Thu) by awesomeman (guest, #85116) [Link]
The distributions publish their own configs, and certainly this is the sanest place to start, although even paring down the hardware can take a bit of time. (now building video4linux will save you alot of compile time) And if you pare down the wrong thing, your resulting kernel won't boot. This last part is what the proposal is meant to address, to prevent from removing features that are 100% required by the user-space you are going to boot. The kernel already has this concept for some drivers and features (CONFIG_EXPERT).
The biggest problem I see with this, is that, 1. for distributions like Debian, this type of definition doesn't really exist, as core things like init system are swappable. and 2. often the software that requires these things doesn't really know it requires these things.
I've submitted patches making systemd a little better when it comes to kernels with slightly less that the Cadillac model of configs. (these were in non-essential helper programs, the system still worked fine)
Kernel configuration for distributions Posted Jul 19, 2012 6:35 UTC (Thu) by drjones (subscriber, #60990) [Link]
CONFIG_EXPERT is a great idea, but it doesn't work as advertised. The idea, according to its help text, is to hide config options from the config menu that most people would never want to modify (options for "non-standard" kernels). However, if you flip this option on, you not only expose those options for modification, but several defaults are *changed*, giving your config an embedded personality. If you're not building an embedded kernel, then EXPERT isn't useful. Getting EXPERT to work as advertised, or implementing some other scheme that hides/exposes standard options, makes sense in order to reduce config menu complexity. An overhaul of config option default value management (maybe with some hierarchical defconfig type scheme) might also be nice.
Kernel configuration for distributions Posted Jul 19, 2012 15:15 UTC (Thu) by WolfWings (guest, #56790) [Link]
The problem is actually that 'EXPERT=n' sets several options certain ways, but their default values are not those settings.
So technically, turning EXPERT=y is returning things to their true defaults, that 'embedded personality' as you put it.
I.E. I believe this would count as a kernel bug of sorts: The defaults for some values do not match their 'EXPERT=n' case, causing toggling that to change other unrelated features when nothing else has been changed.
Kernel configuration for distributions Posted Jul 19, 2012 16:00 UTC (Thu) by drjones (subscriber, #60990) [Link]
I can see how the use of 'default !EXPERT' in Kconfig files can be interpreted this way, and it may be the case for some of 'default !EXPERT' options. However, if you take the options in usr/Kconfig, for example, and look at commits
73d8a12f0529 bzip2/lzma: move CONFIG_RD_* options under CONFIG_EMBEDDED
you'll see from the commit message of 73d8a12f0529 that the toggling default was selected with the init section size of the kernel for embedded systems in mind, and then later 6a108a14fa35 simply renamed EMBEDDED. IMHO, the general symbol name EXPERT should do nothing except expose more options to the menu. Toggling defaults to be more embedded friendly was better left to the symbol EMBEDDED.
|
|||||||||||||