On Sun, Dec 11, 2016 at 7:12 PM, Rob Landley <[email protected]> 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. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
