[3/9] mtd-utils: disable LZO by default

LZO is a fairly obsolete compression format these days, so disable it by
default.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 meta/recipes-devtools/mtd/mtd-utils_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On Tue, 2022-05-24 at 16:23 +0100, Ross Burton wrote:
> LZO is a fairly obsolete compression format these days, so disable it by
> default.
> 
> Signed-off-by: Ross Burton <ross.burton@arm.com>
> ---
>  meta/recipes-devtools/mtd/mtd-utils_git.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/mtd/mtd-utils_git.bb b/meta/recipes-devtools/mtd/mtd-utils_git.bb
> index 3318277477f..8931e870324 100644
> --- a/meta/recipes-devtools/mtd/mtd-utils_git.bb
> +++ b/meta/recipes-devtools/mtd/mtd-utils_git.bb
> @@ -23,7 +23,7 @@ S = "${WORKDIR}/git"
>  # xattr support creates an additional compile-time dependency on acl because
>  # the sys/acl.h header is needed. libacl is not needed and thus enabling xattr
>  # regardless whether acl is enabled or disabled in the distro should be okay.
> -PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'xattr', d)} lzo jffs ubifs"
> +PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'xattr', d)} jffs ubifs"
>  PACKAGECONFIG[lzo] = "--with-lzo,--without-lzo,lzo"
>  PACKAGECONFIG[xattr] = "--with-xattr,--without-xattr,acl"
>  PACKAGECONFIG[crypto] = "--with-crypto,--without-crypto,openssl"

This and kernel compression are the two pieces that worry me a little.
LZO is still probably one of the best speed/size compromises and was
the reason it was added to jffs2. I'm not sure there are many devices
that still use flash directly via jffs2 but this probably still does
have a use there. Obviously it would still be in meta-oe but I'm
worried the "off by default" will catch out a few old BSPs and be a
pain to enable. At lot of this history was paged out in long term
storage!

Cheers,

Richard

> This and kernel compression are the two pieces that worry me a little.
> LZO is still probably one of the best speed/size compromises and was
> the reason it was added to jffs2. I'm not sure there are many devices
> that still use flash directly via jffs2 but this probably still does
> have a use there. Obviously it would still be in meta-oe but I'm
> worried the "off by default" will catch out a few old BSPs and be a
> pain to enable. At lot of this history was paged out in long term
> storage!

Enabling should just be a matter of pulling in meta-oe and flipping the packageconfigs, so I don’t see this as a huge problem.

Looking in the time machine that is meta-handheld, I see the zaurus machines turn on LZO in the JFFS2 kernel module, but they also build UBIFS images which explicitly use zlib instead of lzo.  UBIFS also support Zstd now, so that’s probably a better option all around: it compresses almost as well as zlib but almost as fast as lzo[1].

Ross

[1] from btrfs benchmarks at https://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git/commit/?h=next&id=5c1aab1dd5445ed8bdcdbb575abc1b0d7ee5b2e7

On Wed, 2022-05-25 at 10:34 +0000, Ross Burton wrote:
> > This and kernel compression are the two pieces that worry me a
> > little.
> > LZO is still probably one of the best speed/size compromises and
> > was
> > the reason it was added to jffs2. I'm not sure there are many
> > devices
> > that still use flash directly via jffs2 but this probably still
> > does
> > have a use there. Obviously it would still be in meta-oe but I'm
> > worried the "off by default" will catch out a few old BSPs and be a
> > pain to enable. At lot of this history was paged out in long term
> > storage!
> 
> Enabling should just be a matter of pulling in meta-oe and flipping
> the packageconfigs, so I don’t see this as a huge problem.

My worry is that it changes the task checksums for the native tools and
means the BSP can never be YP Compat.

> Looking in the time machine that is meta-handheld, I see the zaurus
> machines turn on LZO in the JFFS2 kernel module, but they also build
> UBIFS images which explicitly use zlib instead of lzo.  UBIFS also
> support Zstd now, so that’s probably a better option all around: it
> compresses almost as well as zlib but almost as fast as lzo[1].

If the zaurus moved to ubifs, there is probably less of an issue and
just the kernel boot time remains but I'd hope zstd is being used there
too now (or will be).

Cheers,

Richard