{"id":1044,"date":"2019-12-19T13:32:23","date_gmt":"2019-12-19T12:32:23","guid":{"rendered":"https:\/\/blogs.gentoo.org\/mgorny\/?p=1044"},"modified":"2019-12-20T13:19:45","modified_gmt":"2019-12-20T12:19:45","slug":"a-distribution-kernel-for-gentoo","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/mgorny\/2019\/12\/19\/a-distribution-kernel-for-gentoo\/","title":{"rendered":"A\u00a0distribution kernel for\u00a0Gentoo"},"content":{"rendered":"<p>The&nbsp;traditional Gentoo way of&nbsp;getting a&nbsp;kernel is to&nbsp;install the&nbsp;sources, and&nbsp;then <a rel=\"external\" href=\"https:\/\/wiki.gentoo.org\/wiki\/Handbook:AMD64\/Full\/Installation#Default:_Manual_configuration\">configure and&nbsp;build one yourself<\/a>.  For&nbsp;those who didn&#8217;t want to go through the&nbsp;tedious process of&nbsp;configuring it manually, an&nbsp;alternative route of&nbsp;<a rel=\"external\" href=\"https:\/\/wiki.gentoo.org\/wiki\/Handbook:AMD64\/Full\/Installation#Alternative:_Using_genkernel\">using genkernel<\/a> was provided.  However, neither of&nbsp;those variants was able to&nbsp;really provide the&nbsp;equivalent of&nbsp;kernels provided by&nbsp;binary distributions.<\/p>\n<p>I&nbsp;have manually configured the&nbsp;kernels for my private systems long time ago.  Today, I&nbsp;wouldn&#8217;t really have bothered.  In&nbsp;fact, I&nbsp;realized that for&nbsp;some time I&#8217;m really hesitant to&nbsp;even upgrade them because of&nbsp;the&nbsp;effort needed to&nbsp;update configuration.  The&nbsp;worst part is, whenever a&nbsp;new kernel does not boot, I&nbsp;have to&nbsp;ask myself: is it a&nbsp;real bug, or&nbsp;is it my fault for&nbsp;configuring it wrong?<\/p>\n<p>I&#8217;m not alone in&nbsp;this.  Recently \u041c\u0438\u0445\u0430\u0438\u043b \u041a\u043e\u043b\u044f\u0434\u0430 (zlogene) has talked to&nbsp;me about providing binary kernels for&nbsp;Gentoo.  While I&nbsp;have not strictly implemented what he had in&nbsp;mind, he inspired me to&nbsp;start working on&nbsp;a&nbsp;<em>distribution kernel<\/em>.  The&nbsp;goal was to&nbsp;create a&nbsp;kernel package that users can install to&nbsp;get a&nbsp;working kernel with minimal effort, and&nbsp;that would be&nbsp;upgraded automatically as&nbsp;part of&nbsp;regular <kbd>@world<\/kbd> upgrades.<\/p>\n<p><!--more--><\/p>\n<h2>Pros and&nbsp;cons of&nbsp;your own kernel<\/h2>\n<p>If&nbsp;I&nbsp;am to&nbsp;justify switching from the&nbsp;old tradition of&nbsp;custom kernels to&nbsp;a&nbsp;universal kernel package, I&nbsp;should start by&nbsp;discussing the&nbsp;reasons why you may want to&nbsp;<em>configure<\/em> a&nbsp;custom kernel in&nbsp;the&nbsp;first place.<\/p>\n<p>In&nbsp;my opinion, the&nbsp;most important feature of&nbsp;a&nbsp;custom kernel is that you can fine-tune it to&nbsp;your hardware.  You just have to&nbsp;build the&nbsp;drivers you need (or&nbsp;may need), and&nbsp;the&nbsp;features you care about.  The&nbsp;modules for my last custom kernel have occupied 44&nbsp;MiB.  The&nbsp;modules for the&nbsp;distribution kernel occupy 294&nbsp;MiB.  Such a&nbsp;difference in&nbsp;size also comes with a&nbsp;proportional increase of&nbsp;build time.  This can be an&nbsp;important argument for&nbsp;people with low-end hardware.  On&nbsp;the&nbsp;other hand, the&nbsp;distribution kernel permits building <em>reusable binary packages<\/em> that can save more computing power.<\/p>\n<p>The&nbsp;traditional Gentoo argument is&nbsp;performance.  However, these days I&nbsp;would be&nbsp;very careful arguing about that.  I&nbsp;suppose you are able to&nbsp;reap benefits if&nbsp;you know how to&nbsp;configure your kernel towards a&nbsp;specific workload.  But then \u2014 a&nbsp;misconfiguration can have the&nbsp;exact opposite effect.  We must not&nbsp;forget that binary distributions are important players in&nbsp;the&nbsp;field \u2014 and&nbsp;the&nbsp;kernel must also be&nbsp;able to&nbsp;achieve good performance when not using a&nbsp;dedicated configuration.<\/p>\n<p>At&nbsp;some point I have worked on&nbsp;achieving a&nbsp;very fast startup.  For&nbsp;this reason I&#8217;ve switched to&nbsp;using LILO as&nbsp;the&nbsp;bootloader, and&nbsp;a&nbsp;kernel suitable for&nbsp;booting my system without an&nbsp;initramfs.  A&nbsp;universal kernel naturally needs an&nbsp;initramfs, and&nbsp;is slower to&nbsp;boot.<\/p>\n<p>The&nbsp;main counterargument is the&nbsp;effort.  As&nbsp;mentioned earlier, I&#8217;ve personally grown tired of&nbsp;having to&nbsp;manually deal with my kernel.  Do&nbsp;the&nbsp;potential gains mentioned outweigh the&nbsp;loss of&nbsp;<em>human time<\/em> on&nbsp;configuring and&nbsp;maintaining a&nbsp;custom kernel?<\/p>\n<h2>Creating a&nbsp;truly universal kernel<\/h2>\n<p>A&nbsp;distribution kernel makes sense only if&nbsp;it works on&nbsp;a&nbsp;wide range of&nbsp;systems.  Furthermore, I&nbsp;didn&#8217;t forget the&nbsp;original idea of&nbsp;binary kernel packages.  I&nbsp;didn&#8217;t want to write an&nbsp;ebuild that can install a&nbsp;working kernel anywhere.  I&nbsp;wanted to&nbsp;create an&nbsp;ebuild that can be&nbsp;used to&nbsp;build a&nbsp;binary package that&#8217;s going to&nbsp;work on&nbsp;a&nbsp;wide range of&nbsp;setups \u2014 including not only different hardware but&nbsp;also bootloaders and&nbsp;<kbd>\/boot<\/kbd> layout.  A&nbsp;package that would work fine both for&nbsp;my \u2018traditional\u2019 LILO setup and&nbsp;UEFI systemd-boot setup.<\/p>\n<p>The&nbsp;first part of&nbsp;a&nbsp;distribution kernel is&nbsp;the&nbsp;right configuration.  I&nbsp;wanted to&nbsp;use a&nbsp;well-tested configuration known to&nbsp;build kernels used on&nbsp;many systems, while at&nbsp;the&nbsp;same time minimizing the&nbsp;maintenance effort on&nbsp;our end.  Reusing the&nbsp;configuration from a&nbsp;binary distro was the&nbsp;obvious solution.  I&nbsp;went for&nbsp;using the&nbsp;config from&nbsp;<a rel=\"external\" href=\"https:\/\/git.archlinux.org\/svntogit\/packages.git\/tree\/trunk?h=packages\/linux\">Arch Linux&#8217;s kernel package<\/a> with minimal changes (e.g. changing the&nbsp;default hostname to&nbsp;Gentoo).<\/p>\n<p>The&nbsp;second part is an&nbsp;initramfs.  Since we need to&nbsp;support a&nbsp;wide variety of&nbsp;setups, we can&#8217;t get away without it.  To&nbsp;follow the&nbsp;configuration used, Dracut was the&nbsp;natural choice.<\/p>\n<p>The&nbsp;third and&nbsp;hardest part is installing it all.  Since I&#8217;ve already set a&nbsp;goal of&nbsp;reusing the&nbsp;same binary package on&nbsp;different filesystem layouts, the&nbsp;actual installation needed to be&nbsp;moved to&nbsp;postinst phase.  Our distribution kernel package installs the&nbsp;kernel into an&nbsp;interim location which is entirely setup-independent, rendering the&nbsp;binary packages setup-agnostic as&nbsp;well.  The&nbsp;initramfs is&nbsp;created and&nbsp;installed into the&nbsp;final location along with the&nbsp;kernel in&nbsp;<kbd>pkg_postinst<\/kbd>.<\/p>\n<p>Support for&nbsp;different install layouts is provided by&nbsp;reusing the&nbsp;<kbd>installkernel<\/kbd> tool, originally installed by&nbsp;debianutils.  As&nbsp;part of&nbsp;the&nbsp;effort, it was extended with initramfs support and&nbsp;moved into a&nbsp;separate&nbsp;<kbd>sys-kernel\/installkernel-gentoo<\/kbd> package.  Furthermore, an&nbsp;alternative <kbd>sys-kernel\/installkernel-systemd-boot<\/kbd> package was created to&nbsp;provide an&nbsp;out-of-the-box support for&nbsp;systemd-boot layout.  If&nbsp;neither of&nbsp;those two work for you, you can easily create your own <kbd>\/usr\/local\/bin\/installkernel<\/kbd> that follows your own layout.<\/p>\n<h2>Summary<\/h2>\n<p>The&nbsp;experimental versions of&nbsp;the&nbsp;distribution kernel are packaged as&nbsp;<kbd>sys-kernel\/vanilla-kernel<\/kbd> (in&nbsp;distinction from&nbsp;<kbd>sys-kernel\/vanilla-sources<\/kbd> that install the&nbsp;sources).  Besides providing the&nbsp;default zero-effort setup, the&nbsp;package supports using your own configuration via&nbsp;savedconfig (but no&nbsp;easy way to&nbsp;update it at&nbsp;the&nbsp;moment).  It also provides a&nbsp;forced flag that can be&nbsp;used by&nbsp;expert users to disable the&nbsp;initramfs.<\/p>\n<p>The&nbsp;primary goal at&nbsp;the&nbsp;moment is to&nbsp;test the&nbsp;package and&nbsp;find bugs that could prevent our users from using it.  In&nbsp;the&nbsp;future, we&#8217;re planning to&nbsp;extend it to&nbsp;other architectures, kernel variants (Gentoo patch set in&nbsp;particular) and&nbsp;LTS versions.  We&#8217;re also considering providing prebuilt binary packages \u2014 however, this will probably be a&nbsp;part of&nbsp;a&nbsp;bigger effort into providing an&nbsp;official Gentoo binhost.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The&nbsp;traditional Gentoo way of&nbsp;getting a&nbsp;kernel is to&nbsp;install the&nbsp;sources, and&nbsp;then configure and&nbsp;build one yourself. For&nbsp;those who didn&#8217;t want to go through the&nbsp;tedious process of&nbsp;configuring it manually, an&nbsp;alternative route of&nbsp;using genkernel was provided. However, neither of&nbsp;those variants was able to&nbsp;really provide the&nbsp;equivalent of&nbsp;kernels provided by&nbsp;binary distributions. I&nbsp;have manually configured the&nbsp;kernels for my private systems long time ago. &hellip; <a href=\"https:\/\/blogs.gentoo.org\/mgorny\/2019\/12\/19\/a-distribution-kernel-for-gentoo\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;A\u00a0distribution kernel for\u00a0Gentoo&#8221;<\/span><\/a><\/p>\n","protected":false},"author":137,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[3],"tags":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/1044"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/users\/137"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/comments?post=1044"}],"version-history":[{"count":27,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/1044\/revisions"}],"predecessor-version":[{"id":1071,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/1044\/revisions\/1071"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/media?parent=1044"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/categories?post=1044"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/tags?post=1044"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}