[Toybox] [PATCH] dmesg -w output shouldn't be buffered.

[Rob Landley]

On 12/09/2016 06:07 PM, enh wrote:
> not particularly --- this would be the first time i've actually
> managed to get it done on friday in several months! but i've certainly
> got plenty of other stuff i should be doing, so no hurry.
> 
> i'm not sure whether you really meant wget (which we don't even
> build), but dmesg is certainly a bit weird now: a lot of the options
> only make sense for one dmesg implementation or the other. and i'm
> assuming you're not prepared to say "screw Linux < 3.5" and just
> delete the old implementation.

Linux 3.5 was release July 2012. It's 4 years old, I generally go for 7
years of support. No, that's too recent to abandon. (I'm aware google
has stopped shipping updates for the Nexus 5 I bought in February 2014.
I'll let you know when the exploits finally render it unusable.)

Also "works without /proc" is also kind of nice for debugging. And
ubuntu 14.04 doesn't have colored dmesg output or -w to compare with so
I don't see this in my netbook. And the new implementation is three
times as much code to do basically the same thing (they keep sticking
ever-more-elaborate prefixes on the dmesg lines).

The new code needs O_NONBLOCK to get the original behavior, involves
retrying for -EPIPE as a common thing, needs an elaborate sscanf()
invocation to parse the data, parses again at the _end_ of lines
(there's data after \n? This comes up?) There's also lines beginning
with spaces that have some strange keyword=value behavior that this
appears not to filter out? (Although nothing in my kernel's generating
them either? Ah, the sscanf fail is doing it.)

You don't need any of it to implement --color, you only need it for -w.
(And once again color is the eefault for terminal output but no
equivalent to "ls --color | more" actually giving you color.) In theory
there's the possibility of a small race between "fetch the buffer" and
"SEEK_END then wait for more output", but there's already a possibility
of losing messages (this is a thing? spinning dmesg so fast you lose
output entirely?) and it's trivial to reverse that and turn it into a
possibility of _duplicate_ messages_ by doing the SEEK_END before the
klogctl fetch, with a timestamp in microsecends if I really cared about
detecting that, which I probably don't?

If there's SEEK_END there should be a command line option using it to
_just_ show new messages without the existing ones. Logically it's -W,
but of course that's not implemented by
http://man7.org/linux/man-pages/man1/dmesg.1.html because why would they
do that?

Declaring 8k on the stack is impolite to nommu systems...

Sigh. Really not a fan of this new API. Grumble grumble.

Rob