lkml.org 
[lkml]   [2018]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 36/38] vfs: Add a sample program for the new mount API [ver #10]
    On Mon, Jul 30, 2018 at 11:38 AM Matthew Wilcox <willy@infradead.org> 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

    \
     
     \ /
      Last update: 2018-07-30 20:59    [W:3.392 / U:0.180 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site