From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <chao@kernel.org>,
Randy Dunlap <rdunlap@infradead.org>,
linux-f2fs-devel@lists.sourceforge.net,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] f2fs: compress: Allow modular (de)compression algorithms
Date: Tue, 23 Feb 2021 08:42:26 +0100 [thread overview]
Message-ID: <CAMuHMdX-t4Z27RnWn0Sp1AoO3A=+aT8GXkcGC5gSArtm+W9w1Q@mail.gmail.com> (raw)
In-Reply-To: <CAK7LNARxO6O7aRwzJ+i9hEGvWBTCukpwGBC6B79c7UdO=f0Ymw@mail.gmail.com>
Hi Yamada-san,
On Tue, Feb 23, 2021 at 7:31 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
> On Mon, Feb 22, 2021 at 9:59 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > If F2FS_FS is modular, enabling the compressions options
> > F2FS_FS_{LZ4,LZ4HZ,LZO,LZORLE,ZSTD} will make the (de)compression
> > algorithms {LZ4,LZ4HC,LZO,ZSTD}_{,DE}COMPRESS builtin instead of
> > modular, as the former depend on an intermediate boolean
> > F2FS_FS_COMPRESSION, which in-turn depends on tristate F2FS_FS.
> >
> > Indeed, if a boolean symbol A depends directly on a tristate symbol B
> > and selects another tristate symbol C:
> >
> > tristate B
> >
> > tristate C
> >
> > bool A
> > depends on B
> > select C
> >
> > and B is modular, then C will also be modular.
> >
> > However, if there is an intermediate boolean D in the dependency chain
> > between A and B:
> >
> > tristate B
> >
> > tristate C
> >
> > bool D
> > depends on B
> >
> > bool A
> > depends on D
> > select C
> >
> > then the modular state won't propagate from B to C, and C will be
> > builtin instead of modular.
> >
> > Fix this by making the various compression options depend directly on
> > F2FS_FS using a big if/endif block. Drop the now superfluous
> > dependencies on F2FS_FS from individual symbols.
> >
> > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > ---
> > Perhaps the propagation logic in Kconfig should be fixed instead?
> > Else people may reintroduce this issue when removing seemingly-unneeded
> > dependencies.
>
> I checked the code in menu_finalize(), and this seems to work like this.
>
> I discussed the oddity of the select behavior before
> (https://lore.kernel.org/linux-kbuild/e1a6228d-1341-6264-d97a-e2bd52a65c82@infradead.org/),
> but I was not confident about what the right direction was.
>
>
> Anyway, the behavior is obscure from the current code.
>
> If you want to make this more robust,
> you can write as follows:
>
> config F2FS_FS
> tristate "F2FS filesystem support"
> depends on BLOCK
> select NLS
> select CRYPTO
> select CRYPTO_CRC32
> select F2FS_FS_XATTR if FS_ENCRYPTION
> select FS_ENCRYPTION_ALGS if FS_ENCRYPTION
> select LZO_COMPRESS if F2FS_FS_LZO
> select LZO_DECOMPRESS if F2FS_FS_LZO
> select LZ4_COMPRESS if F2FS_FS_LZ4
> select LZ4_DECOMPRESS if F2FS_FS_LZ4
> select LZ4HC_COMPRESS if F2FS_FS_LZ4HC
> select ZSTD_COMPRESS if F2FS_FS_ZSTD
> select ZSTD_DECOMPRESS if F2FS_FS_ZSTD
>
> The code is a bit clumsy, but it is clear
> that the module (F2FS_FS) is selecting the
> compress/decompress libraries.
Actually the above is what I tried first ;-) Works fine.
Then I started to look for similar cases in other file systems (e.g.
EROFS_FS_ZIP), and discovered the issue doesn't happen there, which
sparked my investigation. So I settled on the direct dependency,
because it keeps all compression-related logic together.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
next prev parent reply other threads:[~2021-02-23 7:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-22 12:59 [PATCH] f2fs: compress: Allow modular (de)compression algorithms Geert Uytterhoeven
2021-02-23 6:30 ` Masahiro Yamada
2021-02-23 7:42 ` Geert Uytterhoeven [this message]
2021-02-26 2:14 ` [f2fs-dev] " Chao Yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMuHMdX-t4Z27RnWn0Sp1AoO3A=+aT8GXkcGC5gSArtm+W9w1Q@mail.gmail.com' \
--to=geert@linux-m68k.org \
--cc=chao@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=rdunlap@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).