On Mon, Jul 30, 2018 at 11:38 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
>
> I wasn't proposing putting gettext in the kernel. I was reacting to
> Pavel saying "You can't return English strings from the kernel, you have
> to translate numbers into any language's strings".
The problem with gettext() is that if you *don't* have the strings
marked for translated at the source, you're going to have a hard time
with anything but the simplest fixed strings.
When the kernel does something like
mntinfo("Option %s can not take value %d", opt->name, opt->value);
a gettext() interface inside the kernel (which really would be nasty)
would have seen the format string and the values independently and
would have generated the translation database from that.
But once the string has been generated, it can now be thousands of
different strings, and you can't just look them up from a table any
more.
Real examples from David's patch-series:
errorf(fc, "%s: Lookup failure for '%s'",
desc->name, param->key);
errorf(fc, "%s: Non-blockdev passed to '%s'",
desc->name, param->key);
which means that by the time user space sees it, you can't just "look
up the string". The string will have various random key names etc in
it.
But the alternative to pass things as format strings and raw data, and
having all the rules for a "good gettext interface" are worse. It gets
very ugly very quickly.
So I really think the best option is "Ignore the problem". The system
calls will still continue to report the basic error numbers (EINVAL
etc), and the extended error strings will be just that: extended error
strings. Ignore them if you can't understand them.
That said, people have wanted these kinds of extended error
descriptors forever, and the reason we haven't added them is that it
generally is more pain than it is necessarily worth. I'm not actually
at all convinced that has magically changed with the mount
configuration thing.
Linus
