diff mbox series

[v4,1/2] Kconfig: add btrfs to distro boot

Message ID 20200117195905.26404-1-matthias.bgg@kernel.org
State New
Headers show
Series [v4,1/2] Kconfig: add btrfs to distro boot | expand

Commit Message

Matthias Brugger Jan. 17, 2020, 7:59 p.m. UTC
From: Matthias Brugger <mbrugger at 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 at 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(+)

Comments

Matthias Brugger Jan. 20, 2020, 9:34 a.m. UTC | #1
On 17/01/2020 20:59, matthias.bgg at kernel.org wrote:
> From: Matthias Brugger <mbrugger at 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 at 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
>
Tom Rini Jan. 27, 2020, 9:58 p.m. UTC | #2
On Fri, Jan 17, 2020 at 08:59:02PM +0100, matthias.bgg at kernel.org wrote:

> From: Matthias Brugger <mbrugger at 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 at 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!
Marek BehĂșn Jan. 27, 2020, 11:26 p.m. UTC | #3
On Mon, 27 Jan 2020 16:58:06 -0500
Tom Rini <trini at 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.
Tom Rini Jan. 27, 2020, 11:28 p.m. UTC | #4
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 at 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.
Matthias Brugger Jan. 28, 2020, 10:26 a.m. UTC | #5
On 27/01/2020 22:58, Tom Rini wrote:
> On Fri, Jan 17, 2020 at 08:59:02PM +0100, matthias.bgg at kernel.org wrote:
> 
>> From: Matthias Brugger <mbrugger at 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 at 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
Marek BehĂșn Jan. 28, 2020, 1:06 p.m. UTC | #6
On Mon, 27 Jan 2020 18:28:25 -0500
Tom Rini <trini at 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 at 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.
Tom Rini Jan. 28, 2020, 1:30 p.m. UTC | #7
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 at kernel.org wrote:
> > 
> >> From: Matthias Brugger <mbrugger at 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 at 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.
Tom Rini Jan. 28, 2020, 1:31 p.m. UTC | #8
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 at 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 at 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.
diff mbox series

Patch

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