Re: [GIT PULL] unicode patches for 5.17

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, Jan 12, 2022 at 3:59 AM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> This branch has patches from Christoph Hellwig to split the large data
> tables of the unicode subsystem into a loadable module, which allow
> users to not have them around if case-insensitive filesystems are not to
> be used.

As seen by the pr-tracker-bot, I've merged this, but it had several rough spots.

One of them was around the renaming of the utf8data.h file to a .c
file: I fixed up the .gitignore problem myself, but the incorrect
comments still remain.

The Kconfig thing is also just plain badly done.

It's completely pointless and stupid to first have a "bool UNICODE"
question, and then have a "tristate UNICODE_UTF8_DATA" question that
depends on it.

The Kconfig file even *knows* it's pointless and stupid, because it
has comment to the effect, but despite writing that comment,
apparently nobody spent the five seconds actually thinking about how
to do it properly.

The sane and proper thing would have been to have *one* single
tristate question ("unicode y/m/n"), and that's used for the unicode
data module status.

Then the "core unicode" option (currently that "UNICODE" bool
question) would become something just computed off the modular
question:

  config UNICODE
         def_bool UNICODE_UTF8_DATA != n

with no actual user input being needed for it.

And yes, it might be even nicer to just make "UNICODE" itself be the
tristate, and not have a separate config variable at all, but that
would require changes to the users.

In particular, the filesystems that have

    #ifdef CONFIG_UNICODE

would have to be updated to use something like

    #ifdef IS_ENABLED(CONFIG_UNICODE)

instead.

That would probably be a good change, though, and then the 'UNICODE'
config option could just be a tristate, with the support code being
built in for the module case, with just the data being (potentially)
modular.

ANYWAY. I didn't do the above, I only fixed up the trivially annoying
gitconfig thing.

I've said this before, and I'll probably have to say it again: the
kernel config part is likely one of the most painful barriers to
people building their own kernel. Some of it is just because we have
*so* many modules, and there's just a lot of configuration you can do.

But the fact that it's already painful is no excuse to then ask people
_stupid_ questions and making the whole process unnecessarily even
more painful.

                  Linus