linux-kernel - Re: [PATCH 36/38] vfs: Add a sample program for the new mount API [ver #10]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180731005802.GB21725@thunk.org>
Date:   Mon, 30 Jul 2018 20:58:02 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Pavel Machek <pavel@....cz>,
        David Howells <dhowells@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 36/38] vfs: Add a sample program for the new mount API
 [ver #10]

On Mon, Jul 30, 2018 at 04:58:49PM -0700, Matthew Wilcox wrote:
> 
> Way to poison the well by calling it VMS-style error reporting!  As I
> understand it though, VMS reported errors in English with an error code
> that could be looked up in The Wall of documentation.  I'd see David's
> proposal as closer to plan9-style error reporting.

And I'm quite happy with David's proposal.  What I was trying to
strongly argue against (and, yes, I was using some dirty pool when I
called it VMS-style error reporting) was trying to do something more
structured and more I18N friendly.

> But I think it has been a real problem.  I mean, look at ext4.
> 
>                 if (test_opt2(sb, EXPLICIT_DELALLOC)) {
>                         ext4_msg(sb, KERN_ERR, "can't mount with "
>                                  "both data=journal and delalloc");
>                         goto failed_mount;
> ...

... and in practice it's not been a problem, because a *vanishingly*
small number of users actually try to use the more advanced features
of most file systems.  And those that do, can look at dmesg output,
and they can darned will do it in English.

Doing returning something like %FSEXT4-E-NODJNLDELALLOC followed by
English text, so that people who don't know English can look up
%FSEXT4-E-NODJNLDELALLOC in The Wall of 3-ring binders of
documentation is just silly.  And saying we should remove all English
text and returning the text string %FSEXT4-E-NODJNLDELALLOC so that
people don't speak English aren't "disadvantaged" is even sillier.

So to be clear --- I think David's proposal of just returning "Error:"
followed by English text is just fine[1], and doing more than that is
overdesign.  The advantage of dmesg is that it's well understood by
everyone that dmesg is English text meant for experts[2].  The problem
once we move away from dmesg, this tends to cause the I18N brigade to
start agitating for something more complicated.  And if the only
choices were some complex I18N horror through a system call, or just
leaving the (English) text messages in dmesg, I'd vote for dmesg for
sure.

[1] I'd prefer "E: ", "I: ", etc., instead of "Error: " and "Info: "
but that's bike-shedding.

[2] Actually, some 8-9 years ago some Japenese firms tried to push for
VMS-style messages in dmesg.  The only difference is that the message
codes would be looked-up on-line, but aside from not killing as many
trees, it was pretty much the same design.  So my mentioning VMS-style
messages wasn't just being unfair; these sorts of bad ideas seem to
have a habit of coming back like a bad penny, and it's best to give
them the kibosh as quickly as possible.

					- Ted