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

[enh]

On Sun, Dec 11, 2016 at 7:12 PM, Rob Landley <rob at landley.net> wrote:
> 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.)

7-year rule worth adding to the docs?

> 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?)

yeah, this...

> 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.)

...and this both showed up on my desktop kernel.

as for the buffering, i forgot that xputs and xputc also flush. your
switch to xputs (and the existing xputc) works for me.

> 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



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.