Kernel Developers Discuss Improving Kernel Configurations

[phoronix]

Phoronix: Kernel Developers Discuss Improving Kernel Configurations

Jean Delvare, a name commonly associated with the LM_Sensors project while being an employee at SUSE, has raised an important discussion item on the kernel mailing list about improving the kernel configuration (Kconfig) options when building the Linux kernel...

http://www.phoronix.com/vr.php?view=MTY2NDQ

[grndzro]

+1
It is clearly evident that the whole sensor ball of wax is borked to oblivion.
Mabye maintaining legacy or platform specific kernels is called for That way people working on cutting edge features can be more productive.

No idea tho it's all just IMO.

I get the feeling that the kernel bloat is comming to a head.

[ryszardzonk]

I understand mixed responses as mine is mixed too. I just do not know that if the idea is very good or just good.

I mean I started using Linux on a daily basis around kernel 2.6.14 and since then it has ballooned in size, number of features, drivers and all kind of options. I manage to use oldconfig on every new kernel, but if I was to start from the beginning like new user might do and pick by hand just the options I need I would say it is much harder these days than it was back then and improvements in that department would be quite helpful.

[GreatEmerald]

That sounds like a good idea. Gentoo did something similar for the systemd/OpenRC split, so a platform split would be just as well. I have done some kernel configuration from scratch (only since kernel 3.0, not sure how it was earlier), and it certainly takes a while. So these two things and localmodconfig certainly helps. Though it does feel like there could be a better way than nconfig to manage the whole thing; for instance, one recent upgrade to a Gentoo box I did gave me a warning that I should enable some kernel options. That's fine, but where are the options in question? It turns out one of the options is hidden and not selectable to begin with...It shows up in symbol search, but it's just not present where the symbol says it should be... And some kernel options are really confusing. For instance, I need network bridging support, but would the bridge utilities need the other plethora of net options available, or not? If not, would their functionality be degraded? It's really not obvious, and the help sections only talk about super technical things and implementation details that I really don't care about.

Similarly I feel that Gentoo's package resolving tools need an overhaul. At the moment I have to try installing a package (wait for dependencies to be solved), see that there is a USE flag that might be useful, enable it, retry (wait for dependencies to be solved), compare with the previous output to see how many more packages are pulled in, check if this other needless USE flag in this package that was pulled in doesn't cause too many other packages to be pulled in (wait for dependencies to be solved), and in the end add --autounmask-write to it (wait for dependencies to be solved once more). It would be awesome if there was a visual tool that just showed the dependency graph and updated it in real time when one clicks on a USE flag to toggle it. That would be simple and efficient.

[rudregues]

Similarly I feel that Gentoo's package resolving tools need an overhaul. At the moment I have to try installing a package (wait for dependencies to be solved), see that there is a USE flag that might be useful, enable it, retry (wait for dependencies to be solved), compare with the previous output to see how many more packages are pulled in, check if this other needless USE flag in this package that was pulled in doesn't cause too many other packages to be pulled in (wait for dependencies to be solved), and in the end add --autounmask-write to it (wait for dependencies to be solved once more). It would be awesome if there was a visual tool that just showed the dependency graph and updated it in real time when one clicks on a USE flag to toggle it. That would be simple and efficient.

Before installing the package run equery u <package_name>. It will show you all selected USE flags under U. Then you select or deselect USE flags and run emerge <package_name> --ask. Best than nothing...!

[GreatEmerald]

Before installing the package run equery u <package_name>. It will show you all selected USE flags under U. Then you select or deselect USE flags and run emerge <package_name> --ask. Best than nothing...!

I know about that and eix, but it's just not the solution there ought to be...

[Rexilion]

That sounds like a good idea. Gentoo did something similar for the systemd/OpenRC split, so a platform split would be just as well. I have done some kernel configuration from scratch (only since kernel 3.0, not sure how it was earlier), and it certainly takes a while. So these two things and localmodconfig certainly helps. Though it does feel like there could be a better way than nconfig to manage the whole thing; for instance, one recent upgrade to a Gentoo box I did gave me a warning that I should enable some kernel options. That's fine, but where are the options in question? It turns out one of the options is hidden and not selectable to begin with...It shows up in symbol search, but it's just not present where the symbol says it should be... And some kernel options are really confusing. For instance, I need network bridging support, but would the bridge utilities need the other plethora of net options available, or not? If not, would their functionality be degraded? It's really not obvious, and the help sections only talk about super technical things and implementation details that I really don't care about.

Kernel config is not designed for tweaking by end users. I learned this the hard way. For example, a option to probe all TUN's in the SCSI section has an effect on the usb mass-storage module.

I filed a bug before testing it on a vanilla kernel. Which would have revealed it was a .config problem. However, since v3.14 they made it a indirect dependency since someone else stumbled on this as well.

I had VirtualBox failing to load since I did not select CONFIG_MODULE_UNLOAD.

Furthermore, in 'make menuconfig' you can use '/' to search for module names (don't include the CONFIG_ prefix). It should also give an indication where they are (if they are selectable).

Finally, the example for network bridging marks my point. Only if you really know what you are doing you should use 'make menuconfig'.

Similarly I feel that Gentoo's package resolving tools need an overhaul. At the moment I have to try installing a package (wait for dependencies to be solved), see that there is a USE flag that might be useful, enable it, retry (wait for dependencies to be solved), compare with the previous output to see how many more packages are pulled in, check if this other needless USE flag in this package that was pulled in doesn't cause too many other packages to be pulled in (wait for dependencies to be solved), and in the end add --autounmask-write to it (wait for dependencies to be solved once more). It would be awesome if there was a visual tool that just showed the dependency graph and updated it in real time when one clicks on a USE flag to toggle it. That would be simple and efficient.

[shameless advertising]I moved to Arch after Gentoo. It's worth it if you are using i686/x86_64.[/shameless advertising]

Before installing the package run equery u <package_name>. It will show you all selected USE flags under U. Then you select or deselect USE flags and run emerge <package_name> --ask. Best than nothing...!

That will not help you with the snowball effect of enabling USE flags.

[GreatEmerald]

Kernel config is not designed for tweaking by end users. I learned this the hard way. For example, a option to probe all TUN's in the SCSI section has an effect on the usb mass-storage module.

I filed a bug before testing it on a vanilla kernel. Which would have revealed it was a .config problem. However, since v3.14 they made it a indirect dependency since someone else stumbled on this as well.

Yea, that too. nconfig has the "NEW" system for pointing out things that became available after selecting some option, which is nice in theory, but if the option is in another category, you'll probably never find it. Changing one option having the effect of silently changing another one is also annoying.

[shameless advertising]I moved to Arch after Gentoo. It's worth it if you are using i686/x86_64.[/shameless advertising]

I use Gentoo for specialised devices where I actually need the processor-specific capabilities to be used (ultra low-end netbooks, tablets etc.), so distributions that aren't source-based won't work. Everywhere else I use openSUSE (nuts to all that manual config).