custom kernel config

custom kernel config

[Efraim Flashner]

[-- Attachment #1.1: Type: text/plain, Size: 596 bytes --]

I'm playing around with the idea of creating a custom kernel for my
laptop and I started by following Gentoo's kernel config instructions.
I'm including what I have currently. I want to create a kernel which is
good for my laptop and takes less time to build than the standard
kernel. By leaving the #:configuration-file blank I'm only filling in
the fields I supply, right?


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #1.2: kernel.scm --]
[-- Type: text/plain, Size: 6359 bytes --]

(define-module (kernel)
  #:use-module (gnu packages linux))

(define %macbook41-config-options
  `(("CONFIG_USB_NET_RNDIS_HOST" . m)
    ("CONFIG_USB_NET_CDCETHER" . m)
    ("CONFIG_USB_USBNET" . m)
    ("CONFIG_MII" . m)
    ("CONFIG_RT8XXXU" . m)
    ("CONFIG_CRYPTO_ARC4" . m)
    ("CONFIG_RTL8192CU" . m)
    ;; rtlusb
    ("CONFIG_RTL8192C_COMMON" . m)
    ("CONFIG_RTLWIFI" . m)
    ("CONFIG_USB_ACM" . m)
    ("CONFIG_VLAN_8021Q" . m)
    ("CONFIG_GARP" . m)
    ("CONFIG_MRP" . m)
    ("CONFIG_XT_TARGET_CHECKSUM" . m)
    ("CONFIG_IP_NF_MANGLE" . m)
    ("CONFIG_IP_TABLE_MASQUERADE" . m)
    ("CONFIG_IP_NF_NAT" . m)
    ("CONFIG_NF_NAT_IPV4" . m)
    ("CONFIG_NF_NAT" . m)
    ("CONFIG_NETFILTER_XT_MATCH_CONNTRACK" . m)
    ("CONFIG_NF_CONNTRACK" . m)
    ("CONFIG_NF_DEFRAG_IPV6" . m)
    ("CONFIG_NF_DEFRAG_IPV4" . m)
    ("CONFIG_IP_NF_TARGET_REJECT" . m)
    ("CONFIG_NF_REJECT_IPV4" . m)
    ;; tcpudp
    ("CONFIG_BRIDGE" . m)
    ("CONFIG_STP" . m)
    ("CONFIG_LLC" . m)
    ("CONFIG_BRIDGE_EBT_T_FILTER" . m)
    ("CONFIG_BRIDGE_EBTABLES" . m) ; ?
    ("CONFIG_IP6_NF_FILTER" . m)
    ("CONFIG_IP6_NF_IPTABLES" . m)
    ("CONFIG_IP_NF_FILTER" . m)
    ("CONFIG_NET_DEVLINK" . m)
    ;; one of the two following is corrent
    ("CONFIG_IP_NF_TABLES" . m)
    ("CONFIG_IP_NF_IPTABLES" . m)
    ("CONFIG_NETFILTER_XTABLES" . m)
    ("CONFIG_FB_INTEL" . m)
    ("CONFIG_B43" . m)
    ("CONFIG_BCMA" . m)
    ("CONFIG_MAC80211" . m)
    ("CONFIG_INPUT_JOYDEV" . m)
    ("CONFIG_INPUT_LEDS" . m)
    ("CONFIG_CFG80211" . m)
    ("CONFIG_USB_HCD_SSB" . m)
    ("CONFIG_USB_MOUSE" . m)
    ("CONFIG_ITCO_WDT" . m)
    ("CONFIG_ITCO_VENDOR_SUPPORT" . #t)
    ("CONFIG_USB_KBD" . m)
    ("CONFIG_MOUSE_APPLETOUCH" . m)
    ("CONFIG_SENSORS_APPLESMC" . m)
    ("CONFIG_INPUT_POLLDEV" . m)
    ("CONFIG_SENSORS_CORETEMP" . m)
    ("CONFIG_KVM_INTEL" . m)
    ("CONFIG_KVM" . m)
    ("CONFIG_HAVE_KVM_IRQ_BYPASS" . #t)
    ("CONFIG_HID_APPLEIR" . m)
    ("CONFIG_USB_ISIGHTFW" . m)
    ("CONFIG_PCSPKR_PLATFORM" . #t)
    ("CONFIG_I2C_I801" . m)
    ("CONFIG_SND_HDA_CODEC_REALTEK" . m)
    ("CONFIG_FIREWIRE_OHCI" . m)
    ("CONFIG_LPC_ICH" . m)
    ("CONFIG_CRC_ITU_T" . m)
    ("CONFIG_SKY2" . m)
    ("CONFIG_SSB" . m)
    ("CONFIG_DRM_I915" . m)
    ("CONFIG_SND_HDA_INTEL" . m)
    ("CONFIG_ACPI_SBS" . m)
    ("CONFIG_BATTERY_SBS" . m)
    ("CONFIG_CHARGER_SBS" . m)
    ("CONFIG_MANAGER_SBS" . m)
    ("CONFIG_CEC_CORE" . m)
    ("CONFIG_DRM_KMS_HELPER" . m)
    ("CONFIG_SND_HDA_CORE" . m)
    ("CONFIG_SND_HWDEP" . m)
    ("CONFIG_SND_PCM" . m)
    ("CONFIG_DRM" . m)
    ("CONFIG_ACPI_VIDEO" . m)
    ("CONFIG_SND_TIMER" . m)
    ("CONFIG_I2C_ALGOBIT" . m)
    ("CONFIG_BACKLIGHT_APPLE" . m)
    ("CONFIG_HID_APPLE" . m)
    ("CONFIG_FB_SYS_FOPS" . m)
    ("CONFIG_FB_SYS_COPYAREA" . m)
    ("CONFIG_FB_SYS_FILLRECT" . m)
    ("CONFIG_SND" . m)
    ("CONFIG_FB_SYS_IMAGEBLIT" . m)
    ("CONFIG_SOUND" . m)
    ("CONFIG_BTRFS_FS" . m)
    ("CONFIG_XOR_BLOCKS" . m)
    ("CONFIG_RAID6_PQ" . m)
    ("CONFIG_ZSTD_DECOMPRESS" . m)
    ("CONFIG_ZSTD_COMPRESS" . m)
    ("CONFIG_XXHASH" . m)
    ("CONFIG_LIBCRC32C" . m)
    ("CONFIG_HW_RANDOM_VIRTIO" . m)
    ("CONFIG_VIRTIO_CONSOLE" . #t)
    ("CONFIG_VIRTIO_NET" . #t)
    ("CONFIG_VIRTIO_BLK" . #t)
    ("CONFIG_VIRTIO_BALLOON" . #t)
    ("CONFIG_VIRTIO_PCI" . #t)
    ("CONFIG_VIRTIO" . #t)
    ;; virtio_ring
    ("CONFIG_SCSI_ISCI" . m)
    ("CONFIG_SCSI_SAS_LIBSAS" . m)
    ("CONFIG_SCSI_SAS_ATTRS" . m)
    ("CONFIG_PATA_ATIIXP" . m)
    ("CONFIG_PATA_ACPI" . m)
    ("CONFIG_NLS_ISO8859_1" . m)
    ("CONFIG_CRYPTO_WP512" . m)
    ;; is this not a real flag?
    ("CONFIG_CRYPTO_GENERIC" . #t)
    ("CONFIG_CRYPTO_XTS" . m)
    ("CONFIG_DM_CRYPT" . m)
    ("CONFIG_HID" . m)
    ("CONFIG_USB_HID" . m)
    ("CONFIG_USB_UAS" . m)
    ("CONFIG_USB_STORAGE" . m)
    ("CONFIG_SATA_AHCI" . m)
    ("CONFIG_SATA_AHCI_PLATFORM" . m)

    ("CONFIG_USB_EHCI_HCD" . #t)
    ("CONFIG_USB_UHCI_HCD" . #t)

    ("CONFIG_BT" . m)
    ("CONFIG_BT_HCIBTUSB" . m)
    ("CONFIG_BT_BCM" . m)
    ("CONFIG_BT_RTL" . m)
    ("CONFIG_BT_INTEL" . m)

    ;;filesystems
    ("CONFIG_EXT4_FS" . #t)
    ("CONFIG_EXT4_USE_FOR_EXT2" . #t)
    ("CONFIG_XFS_FS" . m)
    ("CONFIG_MSDOS_FS" . m)
    ("CONFIG_VFAT_FS" . #t)
    ("CONFIG_TMPFS" . #t)
    ("CONFIG_DEVTMPFS" . #t)
    ("CONFIG_DEVTMPFS_MOUNT" . #t)
    ("CONFIG_PROC_FS" . #t)
    ("CONFIG_MSDOS_PARTITION" . #t)

    ;;efi-support
    ("CONFIG_EFI_PARTITION" . #t)
    ("CONFIG_EFIVAR_FS" . #t)
    ("CONFIG_EFI_MIXED" . #t)

    ("CONFIG_FW_LOADER" . #t)
    ("CONFIG_FW_LOADER_USER_HELPER" . #t)

    ;;%emulation
    ("CONFIG_IA32_EMULATION" . #t)
    ("CONFIG_X86_X32" . #t)

    ;;default-extra-linux-options
    ("CONFIG_DEVPTS_MULTIPLE_INSTANCES" . #t)
    ;; Modules required for initrd:
    ("CONFIG_NET_9P" . m)
    ("CONFIG_NET_9P_VIRTIO" . m)
    ("CONFIG_VIRTIO_BLK" . m)
    ("CONFIG_VIRTIO_NET" . m)
    ("CONFIG_VIRTIO_PCI" . m)
    ("CONFIG_VIRTIO_BALLOON" . m)
    ("CONFIG_VIRTIO_MMIO" . m)
    ("CONFIG_FUSE_FS" . m)
    ("CONFIG_CIFS" . m)
    ("CONFIG_9P_FS" . m)
    ))

(define %filesystems
  `(
    ("CONFIG_EXT3_FS" . #t)
    ("CONFIG_EXT4_FS" . #t)
    ("CONFIG_XFS_FS" . #t)
    ("CONFIG_XFS_ONLINE_REPAIR" . #t)
    ("CONFIG_XFS_ONLINE_SCRUB" . #t)
    ("CONFIG_MSDOS_FS" . #t)
    ("CONFIG_VFAT_FS" . #t)
    ("CONFIG_TMPFS" . #t)
    ("CONFIG_DEVTMPFS" . #t)
    ("CONFIG_DEVTMPFS_MOUNT" . #t)
    ("CONFIG_PROC_FS" . #t)
    ("CONFIG_MSDOS_PARTITION" . #t)
    ))

(define %efi-support
  `(
    ("CONFIG_EFI_PARTITION" . #t)
    ("CONFIG_EFIVAR_FS" . #t)
    ("CONFIG_EFI_MIXED" . #t)
    ))

(define %emulation
  `(
    ("CONFIG_IA32_EMULATION" . #t)
    ("CONFIG_X86_X32" . #t)
    ))

(define %macbook41-full-config
  (cons* %macbook41-config-options
          %filesystems
          %efi-support
          %emulation
          (@@ (gnu packages linux) %default-extra-linux-options)))

(define-public linux-libre-macbook41
  ((@@ (gnu packages linux) make-linux-libre) (@@ (gnu packages linux) %linux-libre-version)
                    (@@ (gnu packages linux) %linux-libre-hash)
                    '("x86_64-linux")
                    #:extra-version "macbook41"
                    #:patches (@@ (gnu packages linux) %linux-libre-5.0-patches)
                    #:extra-options %macbook41-config-options))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: custom kernel config

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 181 bytes --]

This is very interesting, I've been wanting to do this for a while.
Is it working for you?  What are the before/after build times?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: custom kernel config

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

On Mon, Apr 01, 2019 at 08:30:28PM +0200, Pierre Neidhardt wrote:
> This is very interesting, I've been wanting to do this for a while.
> Is it working for you?  What are the before/after build times?
> 

I haven't checked to see if my custom kernel works yet on my laptop, but
compile time was 43 minutes on my kids' computer. Stock
linux-libre@5.0.5 took 267 minutes.

My custom kernel came in at 34MB, the stock kernel is 251MB.


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: custom kernel config

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

Efraim Flashner <efraim@flashner.co.il> writes:

> I haven't checked to see if my custom kernel works yet on my laptop, but
> compile time was 43 minutes on my kids' computer. Stock
> linux-libre@5.0.5 took 267 minutes.
>
> My custom kernel came in at 34MB, the stock kernel is 251MB.

Great success! :)

My attempts on my Xiaomi Air 13:

- Stock build time: ~50 minutes.
- Custom kernel, starting from nothing: 5-10 minutes.
  It works, but the mousepad and the sound are missing.  I can't figure
  which component is missing.  Does anyone know if there is any reliable
  way to know the kernel config I need for that?

- Custom kernel, starting from Linux-libre and removing components: 40
  minutes.  It works, but I don't understand why it's still so long to
  build.  I've removed almost all devices I didn't need from the "device
  section", but this is clearly not the bottleneck.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: custom kernel config

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

On Tue, Apr 02, 2019 at 10:04:29AM +0200, Pierre Neidhardt wrote:
> Efraim Flashner <efraim@flashner.co.il> writes:
> 
> > I haven't checked to see if my custom kernel works yet on my laptop, but
> > compile time was 43 minutes on my kids' computer. Stock
> > linux-libre@5.0.5 took 267 minutes.
> >
> > My custom kernel came in at 34MB, the stock kernel is 251MB.
> 
> Great success! :)
> 
> My attempts on my Xiaomi Air 13:
> 
> - Stock build time: ~50 minutes.
> - Custom kernel, starting from nothing: 5-10 minutes.
>   It works, but the mousepad and the sound are missing.  I can't figure
>   which component is missing.  Does anyone know if there is any reliable
>   way to know the kernel config I need for that?

I think I used Gentoo's documentation from the handbook¹ and laboriously
going through `lsmod` and grepping our kernel configs (I think) to
figure out what they were called in the kernel.

> 
> - Custom kernel, starting from Linux-libre and removing components: 40
>   minutes.  It works, but I don't understand why it's still so long to
>   build.  I've removed almost all devices I didn't need from the "device
>   section", but this is clearly not the bottleneck.

I started that way too, but I wasn't sure just how much I could take out.

> 
> Cheers!
> 
> -- 
> Pierre Neidhardt
> https://ambrevar.xyz/

¹ https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: custom kernel config

[Ludovic Courtès]

Hello!

Related to that (somewhat :-)), it’d be great to have a kernel config
specialized for VMs that can boot very quickly.

The Kata Containers folks (it has the word “containers” in it but it’s
really about VMs) pride themselves on having a kernel that boots in
600ms in KVM.

Ludo’.

Re: custom kernel config

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

On Mon, Apr 01, 2019 at 09:46:27PM +0200, Ludovic Courtès wrote:
> Hello!
> 
> Related to that (somewhat :-)), it’d be great to have a kernel config
> specialized for VMs that can boot very quickly.
> 
> The Kata Containers folks (it has the word “containers” in it but it’s
> really about VMs) pride themselves on having a kernel that boots in
> 600ms in KVM.
> 

I'll see if I can find their kernel config and Guix-ify it. It should be
easy to test since with one command Guix can build the kernel and the VM.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: custom kernel config

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

Efraim Flashner <efraim@flashner.co.il> writes:

> I'm playing around with the idea of creating a custom kernel

Cool!  I'm curious to know how you're passing the custom config in.  Are
you using the #:extra-options keyword argument of the make-linux-libre
procedure?  Are you passing in a procedure to generate the entire custom
configuration via the #:configuration-file keyword argument?  Something
else?

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: custom kernel config

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

On Wed, Apr 03, 2019 at 01:08:14AM -0700, Chris Marusich wrote:
> Efraim Flashner <efraim@flashner.co.il> writes:
> 
> > I'm playing around with the idea of creating a custom kernel
> 
> Cool!  I'm curious to know how you're passing the custom config in.  Are
> you using the #:extra-options keyword argument of the make-linux-libre
> procedure?  Are you passing in a procedure to generate the entire custom
> configuration via the #:configuration-file keyword argument?  Something
> else?
> 

For the first one I used the #:extra-options route and compiled a list.
The second one I tried I created a custom kernel and left #:defconfig as
#f and inherited that to add a kconfig to the native-inputs.

Once I read a bit more of the kernel documentation it wasn't too bad to
create a list of what I needed.

tar xf $(guix build linux-libre -S)
cd linux-libre<tab>
touch .config
guix environment linux-libre
    make localmodconfig

copy that into .config and fix the formatting

    make localmodconfig

if that works well enough then add "CONFIG_MODULES=y" to .config and
you're ready to try it out. Stock kernel on my slow desktop took 243(?)
minutes, the custom kernel from localmodconfig took 21 minutes, but I
haven't tested it yet.

When I try again on my laptop I'm going to go again with #:extra-options
since I can define the localmodconfig options as
%macbook41-kernel-options and append to it other groups of modules, such
as filesystems, efi support, etc.


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: custom kernel config

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

Thank you Efraim, this is awesome!

Efraim Flashner <efraim@flashner.co.il> writes:

> For the first one I used the #:extra-options route and compiled a list.
> The second one I tried I created a custom kernel and left #:defconfig as
> #f and inherited that to add a kconfig to the native-inputs.

Oh, I think I had missed the #:defconfig option when I tried.

> Once I read a bit more of the kernel documentation it wasn't too bad to
> create a list of what I needed.

Which documentation in particular?

> tar xf $(guix build linux-libre -S)
> cd linux-libre<tab>
> touch .config
> guix environment linux-libre
>     make localmodconfig
>
> copy that into .config

Copy what into .config?

> and fix the formatting
>
>     make localmodconfig

Why fixing the formatting?  How?  With a second `make localmodconfig'?

> if that works well enough then add "CONFIG_MODULES=y" to .config and
> you're ready to try it out.

What does CONFIG_MODULES=y change?  (Not on my computer now, can't check
in my local linux checkout.)

This walkthrough is invaluable in my opinion.  So far I was under the
impression that many members of the Guix community were annoyed by
kernel compilation time and had tried to customize it, but it's really
hard.  This process would make for an excellent blog article in my
opinion! :D

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: custom kernel config

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2989 bytes --]

On Wed, Apr 03, 2019 at 09:49:59PM +0200, Pierre Neidhardt wrote:
> Thank you Efraim, this is awesome!
> 
> Efraim Flashner <efraim@flashner.co.il> writes:
> 
> > For the first one I used the #:extra-options route and compiled a list.
> > The second one I tried I created a custom kernel and left #:defconfig as
> > #f and inherited that to add a kconfig to the native-inputs.
> 
> Oh, I think I had missed the #:defconfig option when I tried.
> 
> > Once I read a bit more of the kernel documentation it wasn't too bad to
> > create a list of what I needed.
> 
> Which documentation in particular?

Documentation/admin-guide/README.rst from inside the kernel tarball
source.

> 
> > tar xf $(guix build linux-libre -S)
> > cd linux-libre<tab>
> > touch .config
> > guix environment linux-libre
> >     make localmodconfig
> >
> > copy that into .config
> 
> Copy what into .config?

the .config you just created at the root of the source tarball

> 
> > and fix the formatting
> >
> >     make localmodconfig
> 
> Why fixing the formatting?  How?  With a second `make localmodconfig'?
> 

running make localconfig spits out a bunch of pseudo-error messages
about modules that are missing in .config. If you copy that whole
message, minus the lines starting with 'WARING', into .config and
then format it as UPERCASE_OPTION=(y|m) it gives the kernel a config
that is usable for it.

so turning lines that look like:
module nouveau did not have configs CONFIG_DRM_NOUVEAU

into lines that look like:
CONFIG_DRM_NOUVEAU=m

> > if that works well enough then add "CONFIG_MODULES=y" to .config and
> > you're ready to try it out.
> 
> What does CONFIG_MODULES=y change?  (Not on my computer now, can't check
> in my local linux checkout.)

CONFIG_MODULES=y lets the modules be loaded and installed separately, if I
remember correctly. Either way, without it the build errors right at the
beginning of the install phase:

starting phase `install'

The present kernel configuration has modules disabled.
Type 'make config' and enable loadable module support.
Then build a kernel with module support enabled.

make: *** [Makefile:1318: modules_install] Error 1

> 
> This walkthrough is invaluable in my opinion.  So far I was under the
> impression that many members of the Guix community were annoyed by
> kernel compilation time and had tried to customize it, but it's really
> hard.  This process would make for an excellent blog article in my
> opinion! :D

I'll try to go ahead and write it up more nicely then. Custom compiling
a kernel sounds really scary, but with Guix's rollbacks and declarative
everything it's actually not too bad.


Currently this doesn't take into account the initrd.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: custom kernel config

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 2935 bytes --]

Efraim Flashner <efraim@flashner.co.il> writes:

> On Wed, Apr 03, 2019 at 09:49:59PM +0200, Pierre Neidhardt wrote:
>> Thank you Efraim, this is awesome!

I second this remark!  It's really helpful to see how you're doing it.
Thank you for taking the time to share with us!

>> > tar xf $(guix build linux-libre -S)
>> > cd linux-libre<tab>
>> > touch .config
>> > guix environment linux-libre
>> >     make localmodconfig
>> >
>> > copy that into .config
>> 
>> Copy what into .config?
>
> the .config you just created at the root of the source tarball

I think there is some confusion here.  When I run "touch .config" and
then run "make localmodconfig", the .config file is not modified.
Perhaps you meant that we need to take the stdout from "make
localmodconfig", save it, and copy it (after massaging it) back into the
.config file?

> running make localconfig spits out a bunch of pseudo-error messages
> about modules that are missing in .config. If you copy that whole
> message, minus the lines starting with 'WARING', into .config and
> then format it as UPERCASE_OPTION=(y|m) it gives the kernel a config
> that is usable for it.
>
> so turning lines that look like:
> module nouveau did not have configs CONFIG_DRM_NOUVEAU
>
> into lines that look like:
> CONFIG_DRM_NOUVEAU=m

I read up a little on the various targets.  The documentation you
mentioned was helpful, "make help" was helpful, the Makefile source was
somewhat helpful, and the contents of
./scripts/kconfig/streamline_config.pl were helpful for understanding
the intent of the "localmodconfig" target.

It sounds like the intended use of "localmodconfig" target is to modify
an existing, non-empty .config file.  With that in mind, how does the
procedure you describe compare to something like the following?

1) Invoke "guix repl".  Then run this to determine the config that would
normally be used to configure the default linux-libre kernel:

  scheme@(guix-user)> (assoc "kconfig" (package-native-inputs linux-libre))
  $1 = ("kconfig" "/gnu/store/cwghfr06cadj2ss1ya6whgczpcba58z3-guix-module-union/share/guile/site/2.2/gnu/packages/aux-files/linux-libre/5.0-x86_64.conf")

2) Copy that file out of the store into .config.

3) Run "make olddefconfig" to non-interactively update the .config file.

4) Run "make localmodconfig" to streamline the .config based on what's
currently loaded.  I expected this target to also be non-interactive,
but to my surprise it still asked me to choose what to set for a few
options.

If you do it this way, you don't have to fix up formatting.  However,
maybe it doesn't produce the same kind of configuration you had in mind.
What do you think?

> Currently this doesn't take into account the initrd.

Do you mean that there are modules or configuration which the initrd
might need, which this procedure might accidentally disable?

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: custom kernel config

[Efraim Flashner]

[-- Attachment #1.1: Type: text/plain, Size: 3724 bytes --]

On Thu, Apr 04, 2019 at 01:44:48AM -0700, Chris Marusich wrote:
> Efraim Flashner <efraim@flashner.co.il> writes:
> 
> > On Wed, Apr 03, 2019 at 09:49:59PM +0200, Pierre Neidhardt wrote:
> >> Thank you Efraim, this is awesome!
> 
> I second this remark!  It's really helpful to see how you're doing it.
> Thank you for taking the time to share with us!
> 
> >> > tar xf $(guix build linux-libre -S)
> >> > cd linux-libre<tab>
> >> > touch .config
> >> > guix environment linux-libre
> >> >     make localmodconfig
> >> >
> >> > copy that into .config
> >> 
> >> Copy what into .config?
> >
> > the .config you just created at the root of the source tarball
> 
> I think there is some confusion here.  When I run "touch .config" and
> then run "make localmodconfig", the .config file is not modified.
> Perhaps you meant that we need to take the stdout from "make
> localmodconfig", save it, and copy it (after massaging it) back into the
> .config file?

Yeah, basically

> 
> > running make localconfig spits out a bunch of pseudo-error messages
> > about modules that are missing in .config. If you copy that whole
> > message, minus the lines starting with 'WARING', into .config and
> > then format it as UPERCASE_OPTION=(y|m) it gives the kernel a config
> > that is usable for it.
> >
> > so turning lines that look like:
> > module nouveau did not have configs CONFIG_DRM_NOUVEAU
> >
> > into lines that look like:
> > CONFIG_DRM_NOUVEAU=m
> 
> I read up a little on the various targets.  The documentation you
> mentioned was helpful, "make help" was helpful, the Makefile source was
> somewhat helpful, and the contents of
> ./scripts/kconfig/streamline_config.pl were helpful for understanding
> the intent of the "localmodconfig" target.
> 
> It sounds like the intended use of "localmodconfig" target is to modify
> an existing, non-empty .config file.  With that in mind, how does the
> procedure you describe compare to something like the following?
> 
> 1) Invoke "guix repl".  Then run this to determine the config that would
> normally be used to configure the default linux-libre kernel:
> 
>   scheme@(guix-user)> (assoc "kconfig" (package-native-inputs linux-libre))
>   $1 = ("kconfig" "/gnu/store/cwghfr06cadj2ss1ya6whgczpcba58z3-guix-module-union/share/guile/site/2.2/gnu/packages/aux-files/linux-libre/5.0-x86_64.conf")
> 
> 2) Copy that file out of the store into .config.
> 
> 3) Run "make olddefconfig" to non-interactively update the .config file.
> 
> 4) Run "make localmodconfig" to streamline the .config based on what's
> currently loaded.  I expected this target to also be non-interactive,
> but to my surprise it still asked me to choose what to set for a few
> options.
> 
> If you do it this way, you don't have to fix up formatting.  However,
> maybe it doesn't produce the same kind of configuration you had in mind.
> What do you think?
> 

This doesn't create a config that is as small as possible, which is what
I was looking for.

> > Currently this doesn't take into account the initrd.
> 
> Do you mean that there are modules or configuration which the initrd
> might need, which this procedure might accidentally disable?
> 

Yeah. I get different errors about missing ahci.ko or scsi.ko, so it's
going to take a bit more work.

> -- 
> Chris

I've started writing up a blog post about it (which I've attached), but
it doesn't work as-is.  More work incoming later I guess.


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #1.2: custom-kernel.md --]
[-- Type: text/plain, Size: 10585 bytes --]

title: Creating and using a custom Linux kernel on Guix System
date: 2019-04-04 00:00
author: Efraim Flashner
tags: kernel, customization
---

Guix is, at its core, a source based distribution with substitutes, and as such building packages from their source code is an expected part of regular package installations and upgrades.  Given this starting point, it makes sense that efforts are made to reduce the amount of time spent compiling packages, and recent changes and upgrades to the building and distribution of substitutes continues to be a topic of discussion within Guix.  One of the packages which I prefer to not build myself is the Linux-Libre kernel.  The kernel, while not requiring an overabundance of RAM to build, does take a very long time on my build machine (which my children argue is actually their Kodi computer), and I will often delay reconfiguring my laptop while I want for a substitute to be prepared by the official build farm.  The official kernel configuration, as is the case with many GNU/Linux distributions, errs on the side of inclusiveness, and this is really what causes the build to take such a long time when I build the package for myself.

The Linux kernel, however, can also just be described as a package installed on my machine, and as such can be customized just like any other package.  The procedure is a little bit different, although this is primarily due to the nature of how the package defintion is written.

The linux-libre kernel package definition is actually a procedure which creates a package.

```scheme
(define* (make-linux-libre version hash supported-systems
                           #:key
                           ;; A function that takes an arch and a variant.
                           ;; See kernel-config for an example.
                           (extra-version #f)
                           (configuration-file #f)
                           (defconfig "defconfig")
                           (extra-options %default-extra-linux-options)
                           (patches (list %boot-logo-patch)))
  ...)
```

The current linux-libre package is for the 5.0.x series, and is declared like this:

```scheme
(define-public linux-libre
  (make-linux-libre %linux-libre-version
                    %linux-libre-hash
                    '("x86_64-linux" "i686-linux" "armhf-linux" "aarch64-linux")
                    #:patches %linux-libre-5.0-patches
                    #:configuration-file kernel-config))
```

Any keys which are not assigned values inherit their default value from the make-linux-libre definition.  When comparing the two snippets above, you may notice that the code comment in the first doesn't actually refer to the extra-version keyword; it is actually for configuration-file.  Because of this, it is not actually easy to include a custom kernel configuration from the definition, but don't worry, there are other ways to work with what we do have.

There are two ways to create a kernel with a custom kernel configuration.  The first is to provide a standard '.config' file during the build process by including an actual '.config' file as a native-input to our custom kernel.  The following is a snippet from the custom 'configure phase of the make-linux-libre package definition:

```scheme
(let ((build  (assoc-ref %standard-phases 'build))
      (config (assoc-ref (or native-inputs inputs) "kconfig")))

  ;; Use a custom kernel configuration file or a default
  ;; configuration file.
  (if config
      (begin
        (copy-file config ".config")
        (chmod ".config" #o666))
      (invoke "make" ,defconfig))
```

Below is a sample kernel package for one of my computers:

```scheme
(define-public linux-libre-E2140
  (let ((base
          ((@@ (gnu packages linux) make-linux-libre)
           (@@ (gnu packages linux) %linux-libre-version)
           (@@ (gnu packages linux) %linux-libre-hash)
           '("x86_64-linux")
           #:extra-version "E2140"
           #:patches (@@ (gnu packages linux) %linux-libre-5.0-patches))))
    (package
      (inherit base)
      (native-inputs
       `(("kconfig" ,(local-file "E2140.config"))
         ,@(package-native-inputs base))))))
```

In the same directory as the file defining linux-libre-E2140 is a file named E2140.config, which is an actual kernel configuration file.  I left the defconfig keyword of make-linux-libre blank, so the only kernel configuration in the package is the one which I included as a native-input.

The second way to create a custom kernel is to pass a new value to the extra-options keyword of the make-linux-libre procedure.  The extra-options keyword works with another function defined right below it:

```scheme
(define %default-extra-linux-options
  `(;; https://lists.gnu.org/archive/html/guix-devel/2014-04/msg00039.html
   ("CONFIG_DEVPTS_MULTIPLE_INSTANCES" . #t)
   ;; Modules required for initrd:
   ("CONFIG_NET_9P" . m)
   ("CONFIG_NET_9P_VIRTIO" . m)
   ("CONFIG_VIRTIO_BLK" . m)
   ("CONFIG_VIRTIO_NET" . m)
   ("CONFIG_VIRTIO_PCI" . m)
   ("CONFIG_VIRTIO_BALLOON" . m)
   ("CONFIG_VIRTIO_MMIO" . m)
   ("CONFIG_FUSE_FS" . m)
   ("CONFIG_CIFS" . m)
   ("CONFIG_9P_FS" . m)))

(define (config->string options)
  (string-join (map (match-lambda
                      ((option . 'm)
                       (string-append option "=m"))
                      ((option . #t)
                       (string-append option "=y"))
                      ((option . #f)
                       (string-append option "=n")))
                    options)
               "\n"))
```

And in the custom configure script from the make-linux-libre package:

```scheme
;; Appending works even when the option wasn't in the
;; file.  The last one prevails if duplicated.
(let ((port (open-file ".config" "a"))
      (extra-configuration ,(config->string extra-options)))
  (display extra-configuration port)
  (close-port port))

(invoke "make" "oldconfig"))))
```

So by not providing a configuraion-file the '.config' starts blank, and then we write into it the collection of flags that we want.  Here's another custom kernel which I have:

```scheme
(define %macbook41-full-config
  (append %macbook41-config-options
          %filesystems
          %efi-support
          %emulation
          (@@ (gnu packages linux) %default-extra-linux-options)))

(define-public linux-libre-macbook41
  ((@@ (gnu packages linux) make-linux-libre) (@@ (gnu packages linux) %linux-libre-version)
                      (@@ (gnu packages linux) %linux-libre-hash)
                      '("x86_64-linux")
                      #:extra-version "macbook41"
                      #:patches (@@ (gnu packages linux) %linux-libre-5.0-patches)
                      #:extra-options %macbook41-config-options))
```

From the above example %filesystems is a collection of flags enabling different filesystem support, %efi-support enables EFI support and %emulation enables my x86_64-linux machine to act in 32-bit mode also.   %defalt-extra-linux-options are the ones quoted above, which had to be added in since I used replaced them in the extra-options keyword.

This all sounds like it should be doable, but how does one even know which modules are required for their system?  The two places I found most helpful to try to answer this question were the [Gentoo Handbook](https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel), and the [documentation](https://www.kernel.org/doc/html/latest/admin-guide/README.html?highlight=localmodconfig) from the kernel itself.  From the kernel documentation, it seems that "make localmodconfig" is the command we want.

In order to actually run `make localmodconfig` we first need to get and unpack the kernel source code:

```shell
tar xf $(guix build linux-libre --source)
```

Once inside the directory containing the source code run `touch .config` to create an initial, empty '.config' to start with.  `make localmodconfig` works by seeing what you already have in '.config' and letting you know what you're missing.  If the file is blank then you're missing everything.  The next step is to run

```shell
make localmodconfig
```

and note the output.  Do note that the '.config' file is still empty.  The output generally contains two types of warnings.  The first start with "WARNING" and can actually be ignored in our case.  The second read:
```shell
module pcspkr did not have configs CONFIG_INPUT_PCSPKR
```

For each of these lines, copy the CONFIG_XXXX_XXXX portion into the '.config' in the directory, and append "=m", so in the end it looks like this:
```shell
CONFIG_INPUT_PCSPKR=m
CONFIG_VIRTIO=m
```

After copying all the configuration options, run `make localmodconfig` again to make sure that you don't have any output starting with "module".  After all of these machine specific modules there are a couple more left that are also needed.  CONFIG_MODULES is necessary so that you can build and load modules separately and not have everything built into the kernel.  CONFIG_BLK_DEV_SD is required for reading from hard drives.  It is possible that there are other modules which you will need.

The second way to setup the kernel configuration makes more use of Guix's features and allows you to share configuration segments between different kernels.  For example, all machines using EFI to boot have a number of EFI configuration flags that they need.  It is likely that all the kernels will share a list of filesystems to support.


#### About GNU Guix

[GNU Guix](https://www.gnu.org/software/guix) is a transactional package
manager and an advanced distribution of the GNU system that [respects
user
freedom](https://www.gnu.org/distros/free-system-distribution-guidelines.html).
Guix can be used on top of any system running the kernel Linux, or it
can be used as a standalone operating system distribution for i686,
x86_64, ARMv7, and AArch64 machines.

In addition to standard package management features, Guix supports
transactional upgrades and roll-backs, unprivileged package management,
per-user profiles, and garbage collection.  When used as a standalone
GNU/Linux distribution, Guix offers a declarative, stateless approach to
operating system configuration management.  Guix is highly customizable
and hackable through [Guile](https://www.gnu.org/software/guile)
programming interfaces and extensions to the
[Scheme](http://schemers.org) language.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: custom kernel config

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 173 bytes --]

Fantastic write up!

Couple of typos:

- defalt -> default (multiple times)
- configuraion -> configuration

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: custom kernel config

[Ludovic Courtès]

Hello,

Efraim Flashner <efraim@flashner.co.il> skribis:

> title: Creating and using a custom Linux kernel on Guix System
> date: 2019-04-04 00:00
> author: Efraim Flashner
> tags: kernel, customization

Really nice!

> (define-public linux-libre-E2140
>   (let ((base
>           ((@@ (gnu packages linux) make-linux-libre)
>            (@@ (gnu packages linux) %linux-libre-version)
>            (@@ (gnu packages linux) %linux-libre-hash)
>            '("x86_64-linux")
>            #:extra-version "E2140"
>            #:patches (@@ (gnu packages linux) %linux-libre-5.0-patches))))

Could we make all ‘make-linux-libre’ public to avoid the @@ there?
Otherwise it’s a bit scary, and not something we could recommend since
we’re accessing private variables.

As for %linux-libre-{version,hash}, what about simply doing:

  (package-version linux-libre)

and:

  (origin-sha256 (package-source linux-libre))

Likewise for the patches:

  (origin-patches (package-source linux-libre))

With this detail fixed, I’m all for publishing it!

Thanks for taking the time to write this!

Ludo’.

Re: custom kernel config

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 93 bytes --]

I'll try to test it this week on my laptop.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: custom kernel config

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 78 bytes --]

Any update on the blog post?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: custom kernel config

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 192 bytes --]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Any update on the blog post?

I also intend to look at it and try what Efraim has written, but have
not yet found the time.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: custom kernel config

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

On Sun, May 05, 2019 at 08:46:48PM -0700, Chris Marusich wrote:
> Pierre Neidhardt <mail@ambrevar.xyz> writes:
> 
> > Any update on the blog post?
> 
> I also intend to look at it and try what Efraim has written, but have
> not yet found the time.
> 

I haven't forgotten about it, I was on vacation for a bit and then life
got busy.  I still haven't been able to boot satisfactorally a kernel
I've created, but I'm okay now with leaving the end with something like
"And creating a kernel which interfaces with Guix's initrd is left as an
exercise to the reader."


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: custom kernel config

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

Efraim Flashner <efraim@flashner.co.il> writes:

> I haven't forgotten about it, I was on vacation for a bit and then life
> got busy.  I still haven't been able to boot satisfactorally a kernel
> I've created, but I'm okay now with leaving the end with something like
> "And creating a kernel which interfaces with Guix's initrd is left as an
> exercise to the reader."

:D

What about "Suggestions and contributions about ... initrd... are welcome!"

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: custom kernel config

[Mark H Weaver]

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

> Efraim Flashner <efraim@flashner.co.il> skribis:
>
>> title: Creating and using a custom Linux kernel on Guix System
>> date: 2019-04-04 00:00
>> author: Efraim Flashner
>> tags: kernel, customization
>
> Really nice!
>
>> (define-public linux-libre-E2140
>>   (let ((base
>>           ((@@ (gnu packages linux) make-linux-libre)
>>            (@@ (gnu packages linux) %linux-libre-version)
>>            (@@ (gnu packages linux) %linux-libre-hash)
>>            '("x86_64-linux")
>>            #:extra-version "E2140"
>>            #:patches (@@ (gnu packages linux) %linux-libre-5.0-patches))))
>
> Could we make all ‘make-linux-libre’ public to avoid the @@ there?
> Otherwise it’s a bit scary, and not something we could recommend since
> we’re accessing private variables.

I'm sorry that I didn't see this message sooner, but FWIW: I would
prefer not to export 'make-linux-libre', because I have found it to be a
poorly designed interface in need of replacement, and it would be good
to avoid having to maintain it going forward.

       Mark

Re: custom kernel config

[Ludovic Courtès]

Hello,

Mark H Weaver <mhw@netris.org> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>>> (define-public linux-libre-E2140
>>>   (let ((base
>>>           ((@@ (gnu packages linux) make-linux-libre)
>>>            (@@ (gnu packages linux) %linux-libre-version)
>>>            (@@ (gnu packages linux) %linux-libre-hash)
>>>            '("x86_64-linux")
>>>            #:extra-version "E2140"
>>>            #:patches (@@ (gnu packages linux) %linux-libre-5.0-patches))))
>>
>> Could we make all ‘make-linux-libre’ public to avoid the @@ there?
>> Otherwise it’s a bit scary, and not something we could recommend since
>> we’re accessing private variables.
>
> I'm sorry that I didn't see this message sooner, but FWIW: I would
> prefer not to export 'make-linux-libre', because I have found it to be a
> poorly designed interface in need of replacement, and it would be good
> to avoid having to maintain it going forward.

Yeah, I wasn’t sure.  Do you have specific issues in mind that you think
should be addressed?

Anyway for the post, Efraim could perhaps write:

  (define make-linux-libre
    ;; XXX: Access the internal ‘make-linux-libre’ procedure, which is
    ;; private until its interface has stabilized.  Stay tuned!
    (@@ (gnu packages linux) make-linux-libre))

Thanks,
Ludo’.

[BLOG] custom kernel config

[Efraim Flashner]

[-- Attachment #1.1: Type: text/plain, Size: 573 bytes --]

I've cleaned up the blog post a bit and run it through a spell checker.
I'm unsure about Linux-Libre vs linux-libre, regarding talking about the
kernel and the package. I think I glossed over it well enough that I
didn't actually get a custom kernel up and running on my laptop, but for
the purpose of the blog post I don't think it's actually necessary.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #1.2: custom-kernel.md --]
[-- Type: text/plain, Size: 11540 bytes --]

title: Creating and using a custom Linux kernel on Guix System
date: 2019-05-20 00:00
author: Efraim Flashner
tags: kernel, customization
---

Guix is, at its core, a source based distribution with substitutes, and
as such building packages from their source code is an expected part of
regular package installations and upgrades.  Given this starting point,
it makes sense that efforts are made to reduce the amount of time spent
compiling packages, and recent changes and upgrades to the building and
distribution of substitutes continues to be a topic of discussion within
Guix.  One of the packages which I prefer to not build myself is the
Linux-Libre kernel.  The kernel, while not requiring an overabundance of
RAM to build, does take a very long time on my build machine (which my
children argue is actually their Kodi computer), and I will often delay
reconfiguring my laptop while I want for a substitute to be prepared by
the official build farm.  The official kernel configuration, as is the
case with many GNU/Linux distributions, errs on the side of
inclusiveness, and this is really what causes the build to take such a
long time when I build the package for myself.

The Linux kernel, however, can also just be described as a package
installed on my machine, and as such can be customized just like any
other package.  The procedure is a little bit different, although this
is primarily due to the nature of how the package definition is written.

The linux-libre kernel package definition is actually a procedure which
creates a package.

```scheme
(define* (make-linux-libre version hash supported-systems
                           #:key
                           ;; A function that takes an arch and a variant.
                           ;; See kernel-config for an example.
                           (extra-version #f)
                           (configuration-file #f)
                           (defconfig "defconfig")
                           (extra-options %default-extra-linux-options)
                           (patches (list %boot-logo-patch)))
  ...)
```

The current linux-libre package is for the 5.1.x series, and is
declared like this:

```scheme
(define-public linux-libre
  (make-linux-libre %linux-libre-version
                    %linux-libre-hash
                    '("x86_64-linux" "i686-linux" "armhf-linux" "aarch64-linux")
                    #:patches %linux-libre-5.1-patches
                    #:configuration-file kernel-config))
```

Any keys which are not assigned values inherit their default value from
the make-linux-libre definition.  When comparing the two snippets above,
you may notice that the code comment in the first doesn't actually refer
to the extra-version keyword; it is actually for configuration-file.
Because of this, it is not actually easy to include a custom kernel
configuration from the definition, but don't worry, there are other ways
to work with what we do have.

There are two ways to create a kernel with a custom kernel configuration.
The first is to provide a standard '.config' file during the build
process by including an actual '.config' file as a native-input to our
custom kernel.  The following is a snippet from the custom 'configure
phase of the make-linux-libre package definition:

```scheme
(let ((build  (assoc-ref %standard-phases 'build))
      (config (assoc-ref (or native-inputs inputs) "kconfig")))

  ;; Use a custom kernel configuration file or a default
  ;; configuration file.
  (if config
      (begin
        (copy-file config ".config")
        (chmod ".config" #o666))
      (invoke "make" ,defconfig))
```

Below is a sample kernel package for one of my computers:

```scheme
(define-public linux-libre-E2140
  (let ((base
          ((@@ (gnu packages linux) make-linux-libre)
           (@@ (gnu packages linux) %linux-libre-version)
           (@@ (gnu packages linux) %linux-libre-hash)
           '("x86_64-linux")
           #:extra-version "E2140"
           #:patches (@@ (gnu packages linux) %linux-libre-5.1-patches))))
    (package
      (inherit base)
      (native-inputs
       `(("kconfig" ,(local-file "E2140.config"))
         ,@(package-native-inputs base))))))
```

In the same directory as the file defining linux-libre-E2140 is a file
named E2140.config, which is an actual kernel configuration file.  I
left the defconfig keyword of make-linux-libre blank, so the only kernel
configuration in the package is the one which I included as a native-input.

The second way to create a custom kernel is to pass a new value to the
extra-options keyword of the make-linux-libre procedure.  The
extra-options keyword works with another function defined right below it:

```scheme
(define %default-extra-linux-options
  `(;; https://lists.gnu.org/archive/html/guix-devel/2014-04/msg00039.html
   ("CONFIG_DEVPTS_MULTIPLE_INSTANCES" . #t)
   ;; Modules required for initrd:
   ("CONFIG_NET_9P" . m)
   ("CONFIG_NET_9P_VIRTIO" . m)
   ("CONFIG_VIRTIO_BLK" . m)
   ("CONFIG_VIRTIO_NET" . m)
   ("CONFIG_VIRTIO_PCI" . m)
   ("CONFIG_VIRTIO_BALLOON" . m)
   ("CONFIG_VIRTIO_MMIO" . m)
   ("CONFIG_FUSE_FS" . m)
   ("CONFIG_CIFS" . m)
   ("CONFIG_9P_FS" . m)))

(define (config->string options)
  (string-join (map (match-lambda
                      ((option . 'm)
                       (string-append option "=m"))
                      ((option . #t)
                       (string-append option "=y"))
                      ((option . #f)
                       (string-append option "=n")))
                    options)
               "\n"))
```

And in the custom configure script from the make-linux-libre package:

```scheme
;; Appending works even when the option wasn't in the
;; file.  The last one prevails if duplicated.
(let ((port (open-file ".config" "a"))
      (extra-configuration ,(config->string extra-options)))
  (display extra-configuration port)
  (close-port port))

(invoke "make" "oldconfig"))))
```

So by not providing a configuration-file the '.config' starts blank, and
then we write into it the collection of flags that we want.  Here's
another custom kernel which I have:

```scheme
(define %macbook41-full-config
  (append %macbook41-config-options
          %filesystems
          %efi-support
          %emulation
          (@@ (gnu packages linux) %default-extra-linux-options)))

(define-public linux-libre-macbook41
  ;; XXX: Access the internal 'make-linux-libre' procedure, which is
  ;; private and unexported, and is liable to change in the future.
  ((@@ (gnu packages linux) make-linux-libre) (@@ (gnu packages linux) %linux-libre-version)
                      (@@ (gnu packages linux) %linux-libre-hash)
                      '("x86_64-linux")
                      #:extra-version "macbook41"
                      #:patches (@@ (gnu packages linux) %linux-libre-5.1-patches)
                      #:extra-options %macbook41-config-options))
```

From the above example %filesystems is a collection of flags enabling
different filesystem support, %efi-support enables EFI support and
%emulation enables my x86_64-linux machine to act in 32-bit mode also.
%default-extra-linux-options are the ones quoted above, which had to be
added in since I used replaced them in the extra-options keyword.

This all sounds like it should be doable, but how does one even know
which modules are required for their system?  The two places I found
most helpful to try to answer this question were the [Gentoo
Handbook](https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel),
and the
[documentation](https://www.kernel.org/doc/html/latest/admin-guide/README.html?highlight=localmodconfig)
from the kernel itself.  From the kernel documentation, it seems that
"make localmodconfig" is the command we want.

In order to actually run `make localmodconfig` we first need to get and
unpack the kernel source code:

```shell
tar xf $(guix build linux-libre --source)
```

Once inside the directory containing the source code run `touch .config`
to create an initial, empty '.config' to start with.  `make
localmodconfig` works by seeing what you already have in '.config' and
letting you know what you're missing.  If the file is blank then you're
missing everything.  The next step is to run

```shell
make localmodconfig
```

and note the output.  Do note that the '.config' file is still empty.
The output generally contains two types of warnings.  The first start
with "WARNING" and can actually be ignored in our case.  The second read:
```shell
module pcspkr did not have configs CONFIG_INPUT_PCSPKR
```

For each of these lines, copy the CONFIG_XXXX_XXXX portion into the
'.config' in the directory, and append "=m", so in the end it looks
like this:
```shell
CONFIG_INPUT_PCSPKR=m
CONFIG_VIRTIO=m
```

After copying all the configuration options, run `make localmodconfig`
again to make sure that you don't have any output starting with
"module".  After all of these machine specific modules there are a
couple more left that are also needed.  CONFIG_MODULES is necessary so
that you can build and load modules separately and not have everything
built into the kernel.  CONFIG_BLK_DEV_SD is required for reading from
hard drives.  It is possible that there are other modules which you
will need.

This post does not aim to be a guide to configuring your own kernel
however, so if you do decide to build a custom kernel you'll have to
seek out other guides to create a kernel which is just right for your
needs.

The second way to setup the kernel configuration makes more use of
Guix's features and allows you to share configuration segments between
different kernels.  For example, all machines using EFI to boot have a
number of EFI configuration flags that they need.  It is likely that all
the kernels will share a list of filesystems to support.  By using
variables it is easier to see at a glance what features are enabled and
to make sure you don't have features in one kernel but missing in another.

Left undiscussed however, is Guix's initrd and its customization.  It is
likely that you'll need to modify the initrd on a machine using a custom
kernel, since certain modules which are expected to be built may not be
available for inclusion into the initrd.

Suggestions and contributions toward working toward a satisfactory
custom initrd and kernel are welcome!

#### About GNU Guix

[GNU Guix](https://www.gnu.org/software/guix) is a transactional package
manager and an advanced distribution of the GNU system that [respects
user
freedom](https://www.gnu.org/distros/free-system-distribution-guidelines.html).
Guix can be used on top of any system running the kernel Linux, or it
can be used as a standalone operating system distribution for i686,
x86_64, ARMv7, and AArch64 machines.

In addition to standard package management features, Guix supports
transactional upgrades and roll-backs, unprivileged package management,
per-user profiles, and garbage collection.  When used as a standalone
GNU/Linux distribution, Guix offers a declarative, stateless approach to
operating system configuration management.  Guix is highly customizable
and hackable through [Guile](https://www.gnu.org/software/guile)
programming interfaces and extensions to the
[Scheme](http://schemers.org) language.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [BLOG] custom kernel config

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

Great work!
This proved invaluable for me (and I'm sure for many others), thank you so
much!

Comments:

> added in since I used replaced them in the extra-options keyword.

Typo: "used replaced".

> ```shell
> make localmodconfig
> ```

Should be

```shell
guix environment linux-libre -- make localmodconfig
```

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [BLOG] custom kernel config

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

On Thu, May 16, 2019 at 01:10:37PM +0200, Pierre Neidhardt wrote:
> Great work!
> This proved invaluable for me (and I'm sure for many others), thank you so
> much!
> 
> Comments:
> 
> > added in since I used replaced them in the extra-options keyword.
> 
> Typo: "used replaced".
> 

Ooops, looks like it was supposed to just be "replaced"

> > ```shell
> > make localmodconfig
> > ```
> 
> Should be
> 
> ```shell
> guix environment linux-libre -- make localmodconfig
> ```

Good idea!

> 
> Cheers!
> 
> -- 
> Pierre Neidhardt
> https://ambrevar.xyz/



-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [BLOG] custom kernel config

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 2908 bytes --]

Another thing:

> The next step is to run
>
> ```shell
> make localmodconfig
> ```
>
> and note the output.  Do note that the '.config' file is still empty.
> The output generally contains two types of warnings.  The first start
> with "WARNING" and can actually be ignored in our case.  The second read:
> ```shell
> module pcspkr did not have configs CONFIG_INPUT_PCSPKR
> ```
>
> For each of these lines, copy the CONFIG_XXXX_XXXX portion into the
> '.config' in the directory, and append "=m", so in the end it looks
> like this:
> ```shell
> CONFIG_INPUT_PCSPKR=m
> CONFIG_VIRTIO=m

Since I'm not starting from a blank .config, I wanted to compare the
output of `make localmodconfig' and, even better, automatically enable all
the missing modules.

In my case there was some 150 modules and that would have been a lot of work.

So I wrote those quick and dirty Emacs functions:

--8<---------------cut here---------------start------------->8---
(defun kernel-compare-configs (file1 file2)
  "Go through all CONFIG_* variables in FILE1 and report those in
  file2 which are not set."
  (interactive "f\nf")
  (let ((buffer1 (find-file-noselect file1))
        (buffer2 (find-file-noselect file2))
        result)
    (with-current-buffer buffer1
      (goto-char (point-min))
      (while (search-forward "CONFIG_" nil 'noerror)
        (let ((var (symbol-name (sexp-at-point))))
          (with-current-buffer buffer2
            (goto-char (point-min))
            (when (search-forward var nil 'noerror)
              (forward-char)
              (let ((value (word-at-point)))
                (unless (or (string= value "m")
                            (string= value "y"))
                  (push var result))))))))
    result))

(defun kernel-enable-configs (file variables)
  "Variables must be a list of strings.
Example:
  (\"CONFIG_MODULES\")"
  (let ((buffer (find-file-noselect file)))
    (with-current-buffer buffer
      (dolist (var variables)
        (goto-char (point-min))
        ;; Match exact variable only, e.g. CONFIG_MODULES should not match
        ;; CONFIG_MODULES_TREE_LOOKUP.
        (if (not (re-search-forward (concat var "[= ]") nil 'noerror))
            (warn "Variable %S not found" var)
          (beginning-of-line)
          (let ((kill-whole-line nil))
            (kill-line))
          (insert (format "%s=y" var)))))))

;; Example:
; (kernel-enable-configs
;  "/home/ambrevar/.guix-packages/ambrevar/linux-laptop.conf"
;  (compare-kernel-configs
;   "localmodconfig.config"
;   "/home/ambrevar/.guix-packages/ambrevar/linux-laptop.conf"))
--8<---------------cut here---------------end--------------->8---

The above is not general enough but that's a start.

I wonder if there aren't some dedicated tools out there already.  Anyone?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [BLOG] custom kernel config

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 4545 bytes --]

Hi Efraim,

Efraim Flashner <efraim@flashner.co.il> writes:

> I've cleaned up the blog post a bit and run it through a spell checker.
> I'm unsure about Linux-Libre vs linux-libre, regarding talking about the
> kernel and the package. I think I glossed over it well enough that I
> didn't actually get a custom kernel up and running on my laptop, but for
> the purpose of the blog post I don't think it's actually necessary.
>
> -- 
> Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted
> title: Creating and using a custom Linux kernel on Guix System
> date: 2019-05-20 00:00
> author: Efraim Flashner
> tags: kernel, customization
> ---
>
> Guix is, at its core, a source based distribution with substitutes, and
> as such building packages from their source code is an expected part of
> regular package installations and upgrades.  Given this starting point,
> it makes sense that efforts are made to reduce the amount of time spent
> compiling packages, and recent changes and upgrades to the building and
> distribution of substitutes continues to be a topic of discussion within
> Guix.  One of the packages which I prefer to not build myself is the
> Linux-Libre kernel.  The kernel, while not requiring an overabundance of
> RAM to build, does take a very long time on my build machine (which my
> children argue is actually their Kodi computer), and I will often delay
> reconfiguring my laptop while I want for a substitute to be prepared by
> the official build farm.  The official kernel configuration, as is the
> case with many GNU/Linux distributions, errs on the side of
> inclusiveness, and this is really what causes the build to take such a
> long time when I build the package for myself.
>
> The Linux kernel, however, can also just be described as a package
> installed on my machine, and as such can be customized just like any
> other package.  The procedure is a little bit different, although this
> is primarily due to the nature of how the package definition is written.
>
> The linux-libre kernel package definition is actually a procedure which
> creates a package.
>
> ```scheme
> (define* (make-linux-libre version hash supported-systems
>                            #:key
>                            ;; A function that takes an arch and a variant.
>                            ;; See kernel-config for an example.
>                            (extra-version #f)
>                            (configuration-file #f)
>                            (defconfig "defconfig")
>                            (extra-options %default-extra-linux-options)
>                            (patches (list %boot-logo-patch)))
>   ...)
> ```
>
> The current linux-libre package is for the 5.1.x series, and is
> declared like this:
>
> ```scheme
> (define-public linux-libre
>   (make-linux-libre %linux-libre-version
>                     %linux-libre-hash
>                     '("x86_64-linux" "i686-linux" "armhf-linux" "aarch64-linux")
>                     #:patches %linux-libre-5.1-patches
>                     #:configuration-file kernel-config))
> ```
>
> Any keys which are not assigned values inherit their default value from
> the make-linux-libre definition.  When comparing the two snippets above,
> you may notice that the code comment in the first doesn't actually refer
> to the extra-version keyword; it is actually for configuration-file.
> Because of this, it is not actually easy to include a custom kernel
> configuration from the definition, but don't worry, there are other ways
> to work with what we do have.

Thank you for writing this!  I'm sure many would-be power users are
stymied by the weird Scheme interfaces :-)

I just want to point out an (IMO) easier way to provide a custom kernel
configuration, that does not involve the "make-linux-libre" procedure:

--8<---------------cut here---------------start------------->8---
(define-public linux-libre/custom
  (package
    (inherit linux-libre)
    (native-inputs
     `(("kconfig" ,(local-file "kernel.config"))
       ,@(alist-delete "kconfig"
                       (package-native-inputs linux-libre))))))
--8<---------------cut here---------------end--------------->8---

At the end of the day, Linux-Libre is just a regular package that can be
inherited and overridden like any other :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [BLOG] custom kernel config

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 70 bytes --]

+1, doing that to ;)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [BLOG] custom kernel config

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

On Thu, May 16, 2019 at 04:29:56PM +0200, Marius Bakke wrote:
> Hi Efraim,
> 
> I just want to point out an (IMO) easier way to provide a custom kernel
> configuration, that does not involve the "make-linux-libre" procedure:
> 
> --8<---------------cut here---------------start------------->8---
> (define-public linux-libre/custom
>   (package
>     (inherit linux-libre)
>     (native-inputs
>      `(("kconfig" ,(local-file "kernel.config"))
>        ,@(alist-delete "kconfig"
>                        (package-native-inputs linux-libre))))))
> --8<---------------cut here---------------end--------------->8---
> 
> At the end of the day, Linux-Libre is just a regular package that can be
> inherited and overridden like any other :-)

I added that as an alternative way to use "just" a kconfig file.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [BLOG] custom kernel config

[Mark H Weaver]

Hi Marius,

Marius Bakke <mbakke@fastmail.com> writes:

> I just want to point out an (IMO) easier way to provide a custom kernel
> configuration, that does not involve the "make-linux-libre" procedure:
>
> (define-public linux-libre/custom
>   (package
>     (inherit linux-libre)
>     (native-inputs
>      `(("kconfig" ,(local-file "kernel.config"))
>        ,@(alist-delete "kconfig"
>                        (package-native-inputs linux-libre))))))
>
> At the end of the day, Linux-Libre is just a regular package that can be
> inherited and overridden like any other :-)

I think this is the approach we should promote for now.  I would prefer
to leave 'make-linux-libre' as an internal implementation detail, and
hopefully one with a limited life span.

      Thanks,
        Mark

Re: [BLOG] custom kernel config

[Efraim Flashner]

[-- Attachment #1.1: Type: text/plain, Size: 1361 bytes --]

On Thu, May 16, 2019 at 08:15:16PM -0400, Mark H Weaver wrote:
> Hi Marius,
> 
> Marius Bakke <mbakke@fastmail.com> writes:
> 
> > I just want to point out an (IMO) easier way to provide a custom kernel
> > configuration, that does not involve the "make-linux-libre" procedure:
> >
> > (define-public linux-libre/custom
> >   (package
> >     (inherit linux-libre)
> >     (native-inputs
> >      `(("kconfig" ,(local-file "kernel.config"))
> >        ,@(alist-delete "kconfig"
> >                        (package-native-inputs linux-libre))))))
> >
> > At the end of the day, Linux-Libre is just a regular package that can be
> > inherited and overridden like any other :-)
> 
> I think this is the approach we should promote for now.  I would prefer
> to leave 'make-linux-libre' as an internal implementation detail, and
> hopefully one with a limited life span.
> 
>       Thanks,
>         Mark

I've removed my custom E2140 kernel config example and replaced it with
the above example. I've changed "/custom" to "/E2140". I've also taken
the "Linux-Libre is just a ..." sentence and prepended it to the
example.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #1.2: custom-kernel.md --]
[-- Type: text/plain, Size: 11393 bytes --]

title: Creating and using a custom Linux kernel on Guix System
date: 2019-05-20 00:00
author: Efraim Flashner
tags: kernel, customization
---

Guix is, at its core, a source based distribution with substitutes, and
as such building packages from their source code is an expected part of
regular package installations and upgrades.  Given this starting point,
it makes sense that efforts are made to reduce the amount of time spent
compiling packages, and recent changes and upgrades to the building and
distribution of substitutes continues to be a topic of discussion within
Guix.  One of the packages which I prefer to not build myself is the
Linux-Libre kernel.  The kernel, while not requiring an overabundance of
RAM to build, does take a very long time on my build machine (which my
children argue is actually their Kodi computer), and I will often delay
reconfiguring my laptop while I want for a substitute to be prepared by
the official build farm.  The official kernel configuration, as is the
case with many GNU/Linux distributions, errs on the side of
inclusiveness, and this is really what causes the build to take such a
long time when I build the package for myself.

The Linux kernel, however, can also just be described as a package
installed on my machine, and as such can be customized just like any
other package.  The procedure is a little bit different, although this
is primarily due to the nature of how the package definition is written.

The linux-libre kernel package definition is actually a procedure which
creates a package.

```scheme
(define* (make-linux-libre version hash supported-systems
                           #:key
                           ;; A function that takes an arch and a variant.
                           ;; See kernel-config for an example.
                           (extra-version #f)
                           (configuration-file #f)
                           (defconfig "defconfig")
                           (extra-options %default-extra-linux-options)
                           (patches (list %boot-logo-patch)))
  ...)
```

The current linux-libre package is for the 5.1.x series, and is
declared like this:

```scheme
(define-public linux-libre
  (make-linux-libre %linux-libre-version
                    %linux-libre-hash
                    '("x86_64-linux" "i686-linux" "armhf-linux" "aarch64-linux")
                    #:patches %linux-libre-5.1-patches
                    #:configuration-file kernel-config))
```

Any keys which are not assigned values inherit their default value from
the make-linux-libre definition.  When comparing the two snippets above,
you may notice that the code comment in the first doesn't actually refer
to the extra-version keyword; it is actually for configuration-file.
Because of this, it is not actually easy to include a custom kernel
configuration from the definition, but don't worry, there are other ways
to work with what we do have.

There are two ways to create a kernel with a custom kernel configuration.
The first is to provide a standard '.config' file during the build
process by including an actual '.config' file as a native-input to our
custom kernel.  The following is a snippet from the custom 'configure
phase of the make-linux-libre package definition:

```scheme
(let ((build  (assoc-ref %standard-phases 'build))
      (config (assoc-ref (or native-inputs inputs) "kconfig")))

  ;; Use a custom kernel configuration file or a default
  ;; configuration file.
  (if config
      (begin
        (copy-file config ".config")
        (chmod ".config" #o666))
      (invoke "make" ,defconfig))
```

Below is a sample kernel package for one of my computers.  Linux-Libre
is just like other regular packages and can be inherited and overridden
like any other:

```scheme
(define-public linux-libre/E2140
  (package
    (inherit linux-libre)
    (native-inputs
     `(("kconfig" ,(local-file "E2140.config"))
      ,@(alist-delete "kconfig"
                      (package-native-inputs linux-libre))))))
```

In the same directory as the file defining linux-libre-E2140 is a file
named E2140.config, which is an actual kernel configuration file.  I
left the defconfig keyword of make-linux-libre blank, so the only kernel
configuration in the package is the one which I included as a native-input.

The second way to create a custom kernel is to pass a new value to the
extra-options keyword of the make-linux-libre procedure.  The
extra-options keyword works with another function defined right below it:

```scheme
(define %default-extra-linux-options
  `(;; https://lists.gnu.org/archive/html/guix-devel/2014-04/msg00039.html
   ("CONFIG_DEVPTS_MULTIPLE_INSTANCES" . #t)
   ;; Modules required for initrd:
   ("CONFIG_NET_9P" . m)
   ("CONFIG_NET_9P_VIRTIO" . m)
   ("CONFIG_VIRTIO_BLK" . m)
   ("CONFIG_VIRTIO_NET" . m)
   ("CONFIG_VIRTIO_PCI" . m)
   ("CONFIG_VIRTIO_BALLOON" . m)
   ("CONFIG_VIRTIO_MMIO" . m)
   ("CONFIG_FUSE_FS" . m)
   ("CONFIG_CIFS" . m)
   ("CONFIG_9P_FS" . m)))

(define (config->string options)
  (string-join (map (match-lambda
                      ((option . 'm)
                       (string-append option "=m"))
                      ((option . #t)
                       (string-append option "=y"))
                      ((option . #f)
                       (string-append option "=n")))
                    options)
               "\n"))
```

And in the custom configure script from the make-linux-libre package:

```scheme
;; Appending works even when the option wasn't in the
;; file.  The last one prevails if duplicated.
(let ((port (open-file ".config" "a"))
      (extra-configuration ,(config->string extra-options)))
  (display extra-configuration port)
  (close-port port))

(invoke "make" "oldconfig"))))
```

So by not providing a configuration-file the '.config' starts blank, and
then we write into it the collection of flags that we want.  Here's
another custom kernel which I have:

```scheme
(define %macbook41-full-config
  (append %macbook41-config-options
          %filesystems
          %efi-support
          %emulation
          (@@ (gnu packages linux) %default-extra-linux-options)))

(define-public linux-libre-macbook41
  ;; XXX: Access the internal 'make-linux-libre' procedure, which is
  ;; private and unexported, and is liable to change in the future.
  ((@@ (gnu packages linux) make-linux-libre) (@@ (gnu packages linux) %linux-libre-version)
                      (@@ (gnu packages linux) %linux-libre-hash)
                      '("x86_64-linux")
                      #:extra-version "macbook41"
                      #:patches (@@ (gnu packages linux) %linux-libre-5.1-patches)
                      #:extra-options %macbook41-config-options))
```

From the above example %filesystems is a collection of flags enabling
different filesystem support, %efi-support enables EFI support and
%emulation enables my x86_64-linux machine to act in 32-bit mode also.
%default-extra-linux-options are the ones quoted above, which had to be
added in since I replaced them in the extra-options keyword.

This all sounds like it should be doable, but how does one even know
which modules are required for their system?  The two places I found
most helpful to try to answer this question were the [Gentoo
Handbook](https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel),
and the
[documentation](https://www.kernel.org/doc/html/latest/admin-guide/README.html?highlight=localmodconfig)
from the kernel itself.  From the kernel documentation, it seems that
"make localmodconfig" is the command we want.

In order to actually run `make localmodconfig` we first need to get and
unpack the kernel source code:

```shell
tar xf $(guix build linux-libre --source)
```

Once inside the directory containing the source code run `touch .config`
to create an initial, empty '.config' to start with.  `make
localmodconfig` works by seeing what you already have in '.config' and
letting you know what you're missing.  If the file is blank then you're
missing everything.  The next step is to run

```shell
guix environment linux-libre -- make localmodconfig
```

and note the output.  Do note that the '.config' file is still empty.
The output generally contains two types of warnings.  The first start
with "WARNING" and can actually be ignored in our case.  The second read:
```shell
module pcspkr did not have configs CONFIG_INPUT_PCSPKR
```

For each of these lines, copy the CONFIG_XXXX_XXXX portion into the
'.config' in the directory, and append "=m", so in the end it looks
like this:
```shell
CONFIG_INPUT_PCSPKR=m
CONFIG_VIRTIO=m
```

After copying all the configuration options, run `make localmodconfig`
again to make sure that you don't have any output starting with
"module".  After all of these machine specific modules there are a
couple more left that are also needed.  CONFIG_MODULES is necessary so
that you can build and load modules separately and not have everything
built into the kernel.  CONFIG_BLK_DEV_SD is required for reading from
hard drives.  It is possible that there are other modules which you
will need.

This post does not aim to be a guide to configuring your own kernel
however, so if you do decide to build a custom kernel you'll have to
seek out other guides to create a kernel which is just right for your
needs.

The second way to setup the kernel configuration makes more use of
Guix's features and allows you to share configuration segments between
different kernels.  For example, all machines using EFI to boot have a
number of EFI configuration flags that they need.  It is likely that all
the kernels will share a list of filesystems to support.  By using
variables it is easier to see at a glance what features are enabled and
to make sure you don't have features in one kernel but missing in another.

Left undiscussed however, is Guix's initrd and its customization.  It is
likely that you'll need to modify the initrd on a machine using a custom
kernel, since certain modules which are expected to be built may not be
available for inclusion into the initrd.

Suggestions and contributions toward working toward a satisfactory
custom initrd and kernel are welcome!

#### About GNU Guix

[GNU Guix](https://www.gnu.org/software/guix) is a transactional package
manager and an advanced distribution of the GNU system that [respects
user
freedom](https://www.gnu.org/distros/free-system-distribution-guidelines.html).
Guix can be used on top of any system running the kernel Linux, or it
can be used as a standalone operating system distribution for i686,
x86_64, ARMv7, and AArch64 machines.

In addition to standard package management features, Guix supports
transactional upgrades and roll-backs, unprivileged package management,
per-user profiles, and garbage collection.  When used as a standalone
GNU/Linux distribution, Guix offers a declarative, stateless approach to
operating system configuration management.  Guix is highly customizable
and hackable through [Guile](https://www.gnu.org/software/guile)
programming interfaces and extensions to the
[Scheme](http://schemers.org) language.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [BLOG] custom kernel config

[Ludovic Courtès]

Hello Efraim,

Like I wrote before, I like the tone and how the post addresses the
topic.  So I just have minor cosmetic suggestions, and then I guess you
can push to guix-artwork.git and we can put it on-line maybe tomorrow?

Efraim Flashner <efraim@flashner.co.il> skribis:

> Guix is, at its core, a source based distribution with substitutes, and
                                                         ^~
Perhaps link to
<https://www.gnu.org/software/guix/manual/en/html_node/Substitutes.html>
here.

> as such building packages from their source code is an expected part of
> regular package installations and upgrades.  Given this starting point,
> it makes sense that efforts are made to reduce the amount of time spent
> compiling packages, and recent changes and upgrades to the building and
> distribution of substitutes continues to be a topic of discussion within
> Guix.  One of the packages which I prefer to not build myself is the
       ^
Start a new paragraph here?

> The linux-libre kernel package definition is actually a procedure which
      ^
Please make sure to write `linux-libre` (with backquotes) for all the
identifiers, file names, and commands that appears in the post, notably
all the CONFIG_* identifiers.

Perhaps you can also link to
<https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/linux.scm#n294>?

> (define-public linux-libre-macbook41
>   ;; XXX: Access the internal 'make-linux-libre' procedure, which is
>   ;; private and unexported, and is liable to change in the future.
>   ((@@ (gnu packages linux) make-linux-libre) (@@ (gnu packages linux) %linux-libre-version)

Can this one be rewritten using the ‘inherit’ idiom that was discussed?
If not, that’s probably OK since you explicitly write that this is not
the recommended approach.

Thanks for your work!

Ludo’.

Re: [BLOG] custom kernel config

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2724 bytes --]

On Mon, May 20, 2019 at 04:57:28PM +0200, Ludovic Courtès wrote:
> Hello Efraim,
> 
> Like I wrote before, I like the tone and how the post addresses the
> topic.  So I just have minor cosmetic suggestions, and then I guess you
> can push to guix-artwork.git and we can put it on-line maybe tomorrow?
> 
> Efraim Flashner <efraim@flashner.co.il> skribis:
> 
> > Guix is, at its core, a source based distribution with substitutes, and
>                                                          ^~
> Perhaps link to
> <https://www.gnu.org/software/guix/manual/en/html_node/Substitutes.html>
> here.
> 

Done

> > as such building packages from their source code is an expected part of
> > regular package installations and upgrades.  Given this starting point,
> > it makes sense that efforts are made to reduce the amount of time spent
> > compiling packages, and recent changes and upgrades to the building and
> > distribution of substitutes continues to be a topic of discussion within
> > Guix.  One of the packages which I prefer to not build myself is the
>        ^
> Start a new paragraph here?
> 

Ok

> > The linux-libre kernel package definition is actually a procedure which
>       ^
> Please make sure to write `linux-libre` (with backquotes) for all the
> identifiers, file names, and commands that appears in the post, notably
> all the CONFIG_* identifiers.
> 
> Perhaps you can also link to
> <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/linux.scm#n294>?
> 

I also added one when I got to the snippet referencing line 379.

> > (define-public linux-libre-macbook41
> >   ;; XXX: Access the internal 'make-linux-libre' procedure, which is
> >   ;; private and unexported, and is liable to change in the future.
> >   ((@@ (gnu packages linux) make-linux-libre) (@@ (gnu packages linux) %linux-libre-version)
> 
> Can this one be rewritten using the ‘inherit’ idiom that was discussed?
> If not, that’s probably OK since you explicitly write that this is not
> the recommended approach.

Unfortunately I don't think it's possible. We're modifying the output
from the `make-linux-libre` procedure, not the package and its inputs
it's wrapped in. I don't think it's possible without calling the
procedure, at which point we may as well call it directly.

I also didn't parameterize the %linux-libre-5.1-patches reference, but
buyer beware on that kernel definition :)

> 
> Thanks for your work!
> 
> Ludo’.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [BLOG] custom kernel config

[Ludovic Courtès]

Hello!

It’s on-line now:

  https://gnu.org/s/guix/blog/2019/creating-and-using-a-custom-linux-kernel-on-guix-system/

Thank you, Efraim, and thanks to the reviewers!

Ludo’.

Re: [BLOG] custom kernel config

[zimoun]

Dear,

I do not know if there is an issue from my side but the link returns
"Server Not Found".
Basically, I have the issue with https://www.gnu.org/s/guix/

However, it works for:
http://guix.info/blog/
and without the last blog entry.


All the best,
simon

Re: [BLOG] custom kernel config

[ison]

On Thu, May 16, 2019, Mark H Weaver wrote:
> Marius Bakke <mbakke@fastmail.com> writes:
> 
> > I just want to point out an (IMO) easier way to provide a custom kernel
> > configuration, that does not involve the "make-linux-libre" procedure:
> >
> > (define-public linux-libre/custom
> >   (package
> >     (inherit linux-libre)
> >     (native-inputs
> >      `(("kconfig" ,(local-file "kernel.config"))
> >        ,@(alist-delete "kconfig"
> >                        (package-native-inputs linux-libre))))))
> >
> > At the end of the day, Linux-Libre is just a regular package that can be
> > inherited and overridden like any other :-)
> 
> I think this is the approach we should promote for now.  I would prefer
> to leave 'make-linux-libre' as an internal implementation detail, and
> hopefully one with a limited life span.

Is it also possible to leave make-linux-libre out of the 2nd method presented in
the blog? I can't see any way to modify extra-options without it since in the
package it appears deeply nested inside arguments.