Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200622030222.1370098-1-Jason@zx2c4.com>
In-Reply-To: <20200622030222.1370098-1-Jason@zx2c4.com>
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
Date:   Sat, 11 Jul 2020 16:28:29 -0600
Message-ID: <CAHmME9o84kCsK=J-c59gP9RhhzApkwMeh9Y95UeRG8Cs-2ED=g@mail.gmail.com>
Subject: Re: [PATCH] Revert "kernel/printk: add kmsg SEEK_CUR handling"
To:     Petr Mladek <pmladek@suse.com>, LKML <linux-kernel@vger.kernel.org>
Cc:     Bruno Meneguele <bmeneg@redhat.com>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        David Laight <David.Laight@aculab.com>,
        Linus Torvalds <torvalds@linux-foundation.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sun, Jun 21, 2020 at 9:02 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> This commit broke userspace. Bash uses ESPIPE to determine whether or
> not the file should be read using "unbuffered I/O", which means reading
> 1 byte at a time instead of 128 bytes at a time. I used to use bash to
> read through kmsg in a really quite nasty way:
>
>     while read -t 0.1 -r line 2>/dev/null || [[ $? -ne 142 ]]; do
>        echo "SARU $line"
>     done < /dev/kmsg
>
> This will show all lines that can fit into the 128 byte buffer, and skip
> lines that don't. That's pretty awful, but at least it worked.

FYI, bash finally bumped its read buffer up to 4k, which actually
makes reading /dev/kmsg less awful than previously thought:
http://git.savannah.gnu.org/cgit/bash.git/commit/?id=6edcd70089d71ee8c17bf3298527054b3223be9f
This is probably too mundane to warrant an email, but in case somebody
finds this thread in the future, voila.