Results 1 to 8 of 8

Thread: Kernel Developers Discuss Improving Kernel Configurations

  1. #1
    Join Date
    Jan 2007
    Posts
    14,355

    Default Kernel Developers Discuss Improving Kernel Configurations

    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

  2. #2
    Join Date
    Apr 2014
    Posts
    107

    Default

    +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.

  3. #3
    Join Date
    Mar 2011
    Posts
    90

    Default

    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.

  4. #4
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,522

    Default

    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.

  5. #5
    Join Date
    Jul 2013
    Location
    Brasil
    Posts
    92

    Default

    Quote Originally Posted by GreatEmerald View Post
    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...!

  6. #6
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,522

    Default

    Quote Originally Posted by rudregues View Post
    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...

  7. #7
    Join Date
    Dec 2012
    Posts
    457

    Default

    Quote Originally Posted by GreatEmerald View Post
    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'.

    Quote Originally Posted by GreatEmerald View Post
    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]

    Quote Originally Posted by rudregues View Post
    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.

  8. #8
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,522

    Default

    Quote Originally Posted by Rexilion View Post
    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.

    Quote Originally Posted by Rexilion View Post
    [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).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •