[PATCH] MIPS: Malta: Enable BLK_DEV_INITRD

Subsystems: mips, the rest

STALE1685d

3 messages, 3 authors, 2022-02-09 · open the first message on its own page

[PATCH] MIPS: Malta: Enable BLK_DEV_INITRD

From: Nathan Chancellor <nathan@kernel.org>
Date: 2022-02-08 19:17:57

This configuration is useful for boot testing malta_defconfig in QEMU
with just a simple cpio initrd, instead of a full ext4 rootfs.

This results in an increase of ~164KB of vmlinux (with GCC 11.2.0):

$ diskus vmlinux.before
11.19 MB (11,194,368 bytes)

$ diskus vmlinux.after
11.36 MB (11,358,208 bytes)

This size increase comes from the fact that usr/Kconfig is sourced when
CONFIG_BLK_DEV_INITRD is enabled, which defaults to supporting several
decompression algorithms for compressed initrds. This seems like a
reasonable tradeoff but these configurations could be disabled in the
future if there are complaints about the size increase.

Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/mips/configs/malta_defconfig | 1 +
 1 file changed, 1 insertion(+)
diff --git a/arch/mips/configs/malta_defconfig b/arch/mips/configs/malta_defconfig
index 3321bb576944..3456ac8ded6c 100644
--- a/arch/mips/configs/malta_defconfig
+++ b/arch/mips/configs/malta_defconfig
@@ -4,6 +4,7 @@ CONFIG_HIGH_RES_TIMERS=y
 CONFIG_LOG_BUF_SHIFT=15
 CONFIG_NAMESPACES=y
 CONFIG_RELAY=y
+CONFIG_BLK_DEV_INITRD=y
 CONFIG_EXPERT=y
 # CONFIG_COMPAT_BRK is not set
 CONFIG_SLAB=y
base-commit: dfd42facf1e4ada021b939b4e19c935dcdd55566
-- 
2.35.1

Re: [PATCH] MIPS: Malta: Enable BLK_DEV_INITRD

From: Kees Cook <hidden>
Date: 2022-02-09 03:09:35

On Tue, Feb 08, 2022 at 12:17:26PM -0700, Nathan Chancellor wrote:
This configuration is useful for boot testing malta_defconfig in QEMU
with just a simple cpio initrd, instead of a full ext4 rootfs.

This results in an increase of ~164KB of vmlinux (with GCC 11.2.0):

$ diskus vmlinux.before
11.19 MB (11,194,368 bytes)

$ diskus vmlinux.after
11.36 MB (11,358,208 bytes)

This size increase comes from the fact that usr/Kconfig is sourced when
CONFIG_BLK_DEV_INITRD is enabled, which defaults to supporting several
decompression algorithms for compressed initrds. This seems like a
reasonable tradeoff but these configurations could be disabled in the
future if there are complaints about the size increase.

Signed-off-by: Nathan Chancellor <nathan@kernel.org>
I'm all for having a regular way to test all defconfigs. So, FWIW:

Reviewed-by: Kees Cook <redacted>

-Kees
quoted hunk
---
 arch/mips/configs/malta_defconfig | 1 +
 1 file changed, 1 insertion(+)
diff --git a/arch/mips/configs/malta_defconfig b/arch/mips/configs/malta_defconfig
index 3321bb576944..3456ac8ded6c 100644
--- a/arch/mips/configs/malta_defconfig
+++ b/arch/mips/configs/malta_defconfig
@@ -4,6 +4,7 @@ CONFIG_HIGH_RES_TIMERS=y
 CONFIG_LOG_BUF_SHIFT=15
 CONFIG_NAMESPACES=y
 CONFIG_RELAY=y
+CONFIG_BLK_DEV_INITRD=y
 CONFIG_EXPERT=y
 # CONFIG_COMPAT_BRK is not set
 CONFIG_SLAB=y
base-commit: dfd42facf1e4ada021b939b4e19c935dcdd55566
-- 
2.35.1
-- 
Kees Cook

Re: [PATCH] MIPS: Malta: Enable BLK_DEV_INITRD

From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Date: 2022-02-09 13:35:03

On Tue, Feb 08, 2022 at 12:17:26PM -0700, Nathan Chancellor wrote:
This configuration is useful for boot testing malta_defconfig in QEMU
with just a simple cpio initrd, instead of a full ext4 rootfs.

This results in an increase of ~164KB of vmlinux (with GCC 11.2.0):

$ diskus vmlinux.before
11.19 MB (11,194,368 bytes)

$ diskus vmlinux.after
11.36 MB (11,358,208 bytes)

This size increase comes from the fact that usr/Kconfig is sourced when
CONFIG_BLK_DEV_INITRD is enabled, which defaults to supporting several
decompression algorithms for compressed initrds. This seems like a
reasonable tradeoff but these configurations could be disabled in the
future if there are complaints about the size increase.

Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
 arch/mips/configs/malta_defconfig | 1 +
 1 file changed, 1 insertion(+)
applied to mips-next.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help