[PATCH] Kernel Configuration

[PATCH] Kernel Configuration

[Jason Self]

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

Hello, I wanted to make sure that I was doing this correctly before
committing anything. It seems that it's best to have all of the
kernel's config stuff centrally located. Plus, all of these are
already enabled in the normal config, and I'd argue in a better way.
For example: CONFIG_VIRTIO_BLK should be built in, not a module. Doing
it as a module can cause difficulties when running in a VM in some
cases and the normal config already has it as a built-in.

[-- Attachment #1.2: 0001-gnu-linux-libre-Configuration-options-should-be-spec.patch --]
[-- Type: application/octet-stream, Size: 2064 bytes --]

From aec034aab287ce3ba84139be6f773d0a6144f2f1 Mon Sep 17 00:00:00 2001
From: Jason Self <j@jxself.org>
Date: Wed, 24 Sep 2014 11:37:37 -0700
Subject: [PATCH 1/1] gnu: linux-libre: Configuration options should be
 specified in the configuration file.

* gnu/packages/linux.scm (linux-libre): Configuration options should be specified in the configuration file.

Signed-off-by: Jason Self <j@jxself.org>
---
 gnu/packages/linux.scm |   18 ------------------
 1 file changed, 18 deletions(-)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 3e19c35..110e1f3 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -215,24 +215,6 @@ for SYSTEM, or #f if there is no configuration for SYSTEM."
                      (chmod ".config" #o666))
                    (system* "make" "defconfig"))
 
-               ;; Appending works even when the option wasn't in the
-               ;; file.  The last one prevails if duplicated.
-               (let ((port (open-file ".config" "a")))
-                 (display (string-append "CONFIG_NET_9P=m\n"
-                                         "CONFIG_NET_9P_VIRTIO=m\n"
-                                         "CONFIG_VIRTIO_BLK=m\n"
-                                         "CONFIG_VIRTIO_NET=m\n"
-                                         ;; https://lists.gnu.org/archive/html/guix-devel/2014-04/msg00039.html
-                                         "CONFIG_DEVPTS_MULTIPLE_INSTANCES=y\n"
-                                         "CONFIG_VIRTIO_PCI=m\n"
-                                         "CONFIG_VIRTIO_BALLOON=m\n"
-                                         "CONFIG_VIRTIO_MMIO=m\n"
-                                         "CONFIG_FUSE_FS=m\n"
-                                         "CONFIG_CIFS=m\n"
-                                         "CONFIG_9P_FS=m\n")
-                          port)
-                 (close-port port))
-
                (zero? (system* "make" "oldconfig"))
 
                ;; Call the default `build' phase so `-j' is correctly
-- 
1.7.9.5


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

Re: [PATCH] Kernel Configuration

[Ludovic Courtès]

"Jason Self" <jason@bluehome.net> skribis:

> Hello, I wanted to make sure that I was doing this correctly before
> committing anything. It seems that it's best to have all of the
> kernel's config stuff centrally located. Plus, all of these are
> already enabled in the normal config,

If we are sure there are no changes for these options, this is fine with
me (the current settings are relied on by (gnu system vm).)

> and I'd argue in a better way.  For example: CONFIG_VIRTIO_BLK should
> be built in, not a module. Doing it as a module can cause difficulties
> when running in a VM in some cases and the normal config already has
> it as a built-in.

It doesn’t cause any problems in practice: the #:virtio? parameter of
‘base-initrd’ makes sure that module is loaded early (see
gnu/system/linux-initrd.scm.)

Furthermore I would rather keep CONFIG_VIRTIO_BLK=m rather than =y
precisely because that module only makes sense when running a QEMU
guest and not otherwise.

WDYT?

> From aec034aab287ce3ba84139be6f773d0a6144f2f1 Mon Sep 17 00:00:00 2001
> From: Jason Self <j@jxself.org>
> Date: Wed, 24 Sep 2014 11:37:37 -0700
> Subject: [PATCH 1/1] gnu: linux-libre: Configuration options should be
>  specified in the configuration file.

Rather “gnu: linux-libre: Do not set config options in the build phase.”

> * gnu/packages/linux.scm (linux-libre): Configuration options should be specified in the configuration file.

“Remove config option settings from ‘build-phase’.”

Thanks,
Ludo’.

Re: [PATCH] Kernel Configuration

[Jason Self]

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

Ludovic Courtès said:
> Furthermore I would rather keep CONFIG_VIRTIO_BLK=m rather than =y
> precisely because that module only makes sense when running a QEMU
> guest and not otherwise.
>
> WDYT?

My reason for making it y instead of m is:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/902951

I don't use it myself, but think EC2. My understanding is that
ramdisk-less boot is a popular thing because it speeds up booting and
makes maintenance easier. Ideally it'd be easy to set up Guix anywhere.

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

Re: [PATCH] Kernel Configuration

[Ludovic Courtès]

"Jason Self" <jason@bluehome.net> skribis:

> Ludovic Courtès said:
>> Furthermore I would rather keep CONFIG_VIRTIO_BLK=m rather than =y
>> precisely because that module only makes sense when running a QEMU
>> guest and not otherwise.
>> 
>> WDYT?
>
> My reason for making it y instead of m is:
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/902951
>
> I don't use it myself, but think EC2. My understanding is that
> ramdisk-less boot is a popular thing because it speeds up booting and
> makes maintenance easier. Ideally it'd be easy to set up Guix anywhere.

RAM disks are a pain that results from Linux’s lack of support for the
multiboot spec, if you ask me.  ;-)  It’s a reduced pain in Guix because
there’s an easy, automated way to build initrds.

I’m fine with switching to CONFIG_VIRTIO_BLK=y, but then references to
that module in vm.scm or linux-initrd.scm code must be removed, with a
comment saying that this is expected to be compiled in.

Thanks,
Ludo’.