From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f68.google.com ([209.85.214.68]:53124 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729542AbeG3Ufq (ORCPT ); Mon, 30 Jul 2018 16:35:46 -0400 MIME-Version: 1.0 References: <20180729113749.GA7333@amd> <153271267980.9458.7640156373438016898.stgit@warthog.procyon.org.uk> <153271292330.9458.14583488053811372222.stgit@warthog.procyon.org.uk> <25489.1532953411@warthog.procyon.org.uk> <20180730143104.GB24051@amd> <20180730180842.GA5544@bombadil.infradead.org> <20180730183847.GB5544@bombadil.infradead.org> In-Reply-To: <20180730183847.GB5544@bombadil.infradead.org> From: Linus Torvalds Date: Mon, 30 Jul 2018 11:59:13 -0700 Message-ID: Subject: Re: [PATCH 36/38] vfs: Add a sample program for the new mount API [ver #10] To: Matthew Wilcox Cc: Pavel Machek , David Howells , Al Viro , linux-fsdevel , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Jul 30, 2018 at 11:38 AM Matthew Wilcox 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