Message ID | 20220524152401.1663317-3-ross.burton@arm.com |
---|---|
State | New |
Headers | show |
Series | [1/9] lzo: Add further info to a patch | expand |
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
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"
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(-)