[PATCH v4 1/2] Kconfig: add btrfs to distro boot
From: Matthias Brugger mbrugger@suse.com
Some distributions use btrfs as the default file system. Enable btrfs support by default when using distro boot for all architectures but riscv, as it breaks compilation due to size problems.
Signed-off-by: Matthias Brugger mbrugger@suse.com
---
Changes in v4: - do not build for MIPS either
Changes in v3: - use imply instead of select
Changes in v2: - disable default btrfs support riscv
Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/Kconfig b/Kconfig index d9be0daf23..f96f785c55 100644 --- a/Kconfig +++ b/Kconfig @@ -93,6 +93,7 @@ config DISTRO_DEFAULTS select HUSH_PARSER select SUPPORT_RAW_INITRD select SYS_LONGHELP + imply CMD_BTRFS if !RISCV && !MIPS imply CMD_MII if NET imply USB_STORAGE imply USE_BOOTCOMMAND
From: Matthias Brugger mbrugger@suse.com
CONFIG_DISTRO_DEFAULTS now enables CMD_BTRFS by default, we can delete the config option in the corresponding default configs. Other boards won't build with btrfs enabled so disable the support by default.
Signed-off-by: Matthias Brugger mbrugger@suse.com
---
Changes in v4: - disable for some boards
Changes in v3: None Changes in v2: None
configs/am335x_evm_defconfig | 2 ++ configs/sandbox64_defconfig | 1 - configs/sandbox_defconfig | 1 - configs/socfpga_arria10_defconfig | 2 ++ configs/turris_mox_defconfig | 1 - configs/turris_omnia_defconfig | 1 - 6 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig index 335aa8cfa1..bae0571ed7 100644 --- a/configs/am335x_evm_defconfig +++ b/configs/am335x_evm_defconfig @@ -80,3 +80,5 @@ CONFIG_DYNAMIC_CRC_TABLE=y CONFIG_RSA=y CONFIG_LZO=y # CONFIG_OF_LIBFDT_OVERLAY is not set +# CONFIG_CMD_BTRFS is not set +# CONFIG_FS_BTRFS is not set diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig index 64d1d3102f..0826c06aa9 100644 --- a/configs/sandbox64_defconfig +++ b/configs/sandbox64_defconfig @@ -63,7 +63,6 @@ CONFIG_CMD_REGULATOR=y CONFIG_CMD_AES=y CONFIG_CMD_TPM=y CONFIG_CMD_TPM_TEST=y -CONFIG_CMD_BTRFS=y CONFIG_CMD_CBFS=y CONFIG_CMD_CRAMFS=y CONFIG_CMD_EXT4_WRITE=y diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index d8d8645425..f2d5572f99 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -71,7 +71,6 @@ CONFIG_CMD_REGULATOR=y CONFIG_CMD_AES=y CONFIG_CMD_TPM=y CONFIG_CMD_TPM_TEST=y -CONFIG_CMD_BTRFS=y CONFIG_CMD_CBFS=y CONFIG_CMD_CRAMFS=y CONFIG_CMD_EXT4_WRITE=y diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index b4826548eb..fa7a5681ec 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -50,3 +50,5 @@ CONFIG_TIMER=y CONFIG_SPL_TIMER=y CONFIG_DESIGNWARE_APB_TIMER=y # CONFIG_SPL_WDT is not set +# CONFIG_CMD_BTRFS is not set +# CONFIG_FS_BTRFS is not set diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig index b88cc4b842..89a1c73957 100644 --- a/configs/turris_mox_defconfig +++ b/configs/turris_mox_defconfig @@ -32,7 +32,6 @@ CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y CONFIG_CMD_MVEBU_BUBT=y -CONFIG_CMD_BTRFS=y CONFIG_CMD_EXT4_WRITE=y CONFIG_MAC_PARTITION=y CONFIG_OF_BOARD_FIXUP=y diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig index b6cb9a5f9d..160f1de656 100644 --- a/configs/turris_omnia_defconfig +++ b/configs/turris_omnia_defconfig @@ -49,7 +49,6 @@ CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y CONFIG_CMD_AES=y CONFIG_CMD_HASH=y -CONFIG_CMD_BTRFS=y # CONFIG_SPL_PARTITION_UUIDS is not set CONFIG_DEFAULT_DEVICE_TREE="armada-385-turris-omnia" CONFIG_ENV_IS_IN_SPI_FLASH=y
On 17/01/2020 20:59, matthias.bgg@kernel.org wrote:
From: Matthias Brugger mbrugger@suse.com
Some distributions use btrfs as the default file system. Enable btrfs support by default when using distro boot for all architectures but riscv, as it breaks compilation due to size problems.
Signed-off-by: Matthias Brugger mbrugger@suse.com
Any comments on this? FYI the Travis CI outcome can be seen here: https://travis-ci.org/mbgg/u-boot/builds/638599305
Regards, Matthias
Changes in v4:
- do not build for MIPS either
Changes in v3:
- use imply instead of select
Changes in v2:
- disable default btrfs support riscv
Kconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/Kconfig b/Kconfig index d9be0daf23..f96f785c55 100644 --- a/Kconfig +++ b/Kconfig @@ -93,6 +93,7 @@ config DISTRO_DEFAULTS select HUSH_PARSER select SUPPORT_RAW_INITRD select SYS_LONGHELP
- imply CMD_BTRFS if !RISCV && !MIPS imply CMD_MII if NET imply USB_STORAGE imply USE_BOOTCOMMAND
On Fri, Jan 17, 2020 at 08:59:02PM +0100, matthias.bgg@kernel.org wrote:
From: Matthias Brugger mbrugger@suse.com
Some distributions use btrfs as the default file system. Enable btrfs support by default when using distro boot for all architectures but riscv, as it breaks compilation due to size problems.
Signed-off-by: Matthias Brugger mbrugger@suse.com
This adds around 60kb to many platforms, so I'm not going to take this right now. But I'm not rejecting it outright. My question however is, I was under the impression that the direction distributions were taking was that bootefi would be used to start GRUB2 and that (and its filesystem modules) would be responsible for doing the next steps. So we wouldn't need btrfs support here for example as everything would be picked out of the system partition, which is FAT32. Am I mistaken about the flow here? Thanks!
On Mon, 27 Jan 2020 16:58:06 -0500 Tom Rini trini@konsulko.com wrote:
This adds around 60kb to many platforms, so I'm not going to take this right now.
Off topic: I was wondering how much space could be saved if it were possible to use -Os with LTO in U-Boot.
On Tue, Jan 28, 2020 at 12:26:45AM +0100, Marek Behun wrote:
On Mon, 27 Jan 2020 16:58:06 -0500 Tom Rini trini@konsulko.com wrote:
This adds around 60kb to many platforms, so I'm not going to take this right now.
Off topic: I was wondering how much space could be saved if it were possible to use -Os with LTO in U-Boot.
It's a good question. Step one is to switch to using gcc to link directly.
On Mon, 27 Jan 2020 18:28:25 -0500 Tom Rini trini@konsulko.com wrote:
On Tue, Jan 28, 2020 at 12:26:45AM +0100, Marek Behun wrote:
On Mon, 27 Jan 2020 16:58:06 -0500 Tom Rini trini@konsulko.com wrote:
This adds around 60kb to many platforms, so I'm not going to take this right now.
Off topic: I was wondering how much space could be saved if it were possible to use -Os with LTO in U-Boot.
It's a good question. Step one is to switch to using gcc to link directly.
Tom, another option would be to try to amalge btrfs sources into one file and try to compile it with -Os, I am curious about what would happen. Maybe I'll try sometime this week.
On Tue, Jan 28, 2020 at 02:06:20PM +0100, Marek Behun wrote:
On Mon, 27 Jan 2020 18:28:25 -0500 Tom Rini trini@konsulko.com wrote:
On Tue, Jan 28, 2020 at 12:26:45AM +0100, Marek Behun wrote:
On Mon, 27 Jan 2020 16:58:06 -0500 Tom Rini trini@konsulko.com wrote:
This adds around 60kb to many platforms, so I'm not going to take this right now.
Off topic: I was wondering how much space could be saved if it were possible to use -Os with LTO in U-Boot.
It's a good question. Step one is to switch to using gcc to link directly.
Tom, another option would be to try to amalge btrfs sources into one file and try to compile it with -Os, I am curious about what would happen. Maybe I'll try sometime this week.
Sure, but per the other email I just sent out, just like how I'm not happy about adding a few hundred bytes to hundreds of boards for QSPI support, I'm not happy to see this be the default for a few hundred boards and we need something more fine-grained.
On 27/01/2020 22:58, Tom Rini wrote:
On Fri, Jan 17, 2020 at 08:59:02PM +0100, matthias.bgg@kernel.org wrote:
From: Matthias Brugger mbrugger@suse.com
Some distributions use btrfs as the default file system. Enable btrfs support by default when using distro boot for all architectures but riscv, as it breaks compilation due to size problems.
Signed-off-by: Matthias Brugger mbrugger@suse.com
This adds around 60kb to many platforms, so I'm not going to take this right now. But I'm not rejecting it outright. My question however is, I was under the impression that the direction distributions were taking was that bootefi would be used to start GRUB2 and that (and its filesystem modules) would be responsible for doing the next steps. So we wouldn't need btrfs support here for example as everything would be picked out of the system partition, which is FAT32. Am I mistaken about the flow here? Thanks!
I think the assumption is correct for most of the distributions (if not all). However in distro boot we support e.g. extlinux/sysboot which not necessarily boots a EFI binary. Apart from that, think about a broken system partition. In that case if your distribution has the kernel on a btrfs partition, you would not be able to boot this kernel. That's the reason why we enable ext2 and ext4 support in distro boot.
Regarding the size, I'm aware of the problem, that's why it is set as imply in Kconfig so that individual boards can turn it off. We might think about chaning ext2 and ext4 from select to imply as well as we are at the limit on some platforms.
Regards, Matthias
Regards, Matthias
On Tue, Jan 28, 2020 at 11:26:25AM +0100, Matthias Brugger wrote:
On 27/01/2020 22:58, Tom Rini wrote:
On Fri, Jan 17, 2020 at 08:59:02PM +0100, matthias.bgg@kernel.org wrote:
From: Matthias Brugger mbrugger@suse.com
Some distributions use btrfs as the default file system. Enable btrfs support by default when using distro boot for all architectures but riscv, as it breaks compilation due to size problems.
Signed-off-by: Matthias Brugger mbrugger@suse.com
This adds around 60kb to many platforms, so I'm not going to take this right now. But I'm not rejecting it outright. My question however is, I was under the impression that the direction distributions were taking was that bootefi would be used to start GRUB2 and that (and its filesystem modules) would be responsible for doing the next steps. So we wouldn't need btrfs support here for example as everything would be picked out of the system partition, which is FAT32. Am I mistaken about the flow here? Thanks!
I think the assumption is correct for most of the distributions (if not all). However in distro boot we support e.g. extlinux/sysboot which not necessarily boots a EFI binary. Apart from that, think about a broken system partition. In that case if your distribution has the kernel on a btrfs partition, you would not be able to boot this kernel. That's the reason why we enable ext2 and ext4 support in distro boot.
Regarding the size, I'm aware of the problem, that's why it is set as imply in Kconfig so that individual boards can turn it off. We might think about chaning ext2 and ext4 from select to imply as well as we are at the limit on some platforms.
The extN support portion I thought predates bootefi+GRUB being viable/common and is for when /boot was/is formatted as such.
My concern here (similar to my concern about distro boot + SPI) is that we encourage the default for all boards to be "use distro boot, it makes life easy on users". Both big name distributions support it as well as embedded oriented distributions. Non-Linux supports it. So growth here is very important to consider.
Perhaps what we can talk about, for v2020.07, is a new not-default sub-option of DISTRO_DEFAULTS to make it more robust, as in your use-case and select more filesystems. And move EXT2/EXT4 to that, but also make all existing users keep it enabled (which is a little tricky, but doable of a migration) and add BTRFS. We can even see if it makes sense to add ZFS there too for the BSD folks.
Hi,
Signed-off-by: Matthias Brugger mbrugger@suse.com
Reviewed-by: Petr Vorel pvorel@suse.cz
Kind regards, Petr
participants (5)
-
Marek Behun -
Matthias Brugger -
matthias.bgg＠kernel.org -
Petr Vorel -
Tom Rini