[Toybox] [PATCH] Fix dmesg -c and -C.

[Rob Landley]

On 02/20/2017 12:25 PM, enh wrote:
> ping. dmesg -C/-c still broken; you can always apply your cleanup
> after this patch, when you have time...

Yeah, my bad. I have a reply window open for Daniel Levy's cut stuff too
apologizing for sitting on my own local changes there:

> $ git diff toys/*/cut.c tests/cut.test | diffstat 
>  tests/cut.test   |   33 ++++
>  toys/posix/cut.c |  373 +++++++++++++++++++++----------------------------------
>  2 files changed, 176 insertions(+), 230 deletions(-)

for months now without cycling back around to it.

I suppose what I should do is extract the patch, attach it to the reply
message acknowledging I committed the other patches I backed it out for,
and then... abandon it like I basically have every time I've declared
diff bankruptcy and started developing against a new "clean" checkout.
(I keep meaning to come back to stuff but after 4 years in some cases,
it ain't happening.)

I miss the days when $DAYJOB wasn't in perpetual crisis mode. The theory
behind tomorrow's ELC talk on my mkroot stuff is it forces me to get
mkroot in shape by turning it into a crisis with deadline attached,
which lets me ignore the other crises without deadlines attached. But of
course I'm _also_ supposed to be preparing a table demo the next day for
the Turtle boards we've been sitting on for a year now, in hopes of
forcing us to take preorders and commit to an availability date. (It's a
raspberry pi IIb form factor, all the same I/O devices in the same
layout so it fits in the same cases and everything, but it's got an
Xilinx Spartan 6 LX25 FPGA instead of an ARM SOC, so you load an open
processor bitstream into it to run Linux. Of course I'm demoing it with
j-core, and of course despite having the prototypes most of a year now
we hadn't implemented an HDMI text console until... hardware has a new
bitstream sitting in my inbox, kernel side driver they told me to write.
So I guess that's my tomorrow night. And trying to buy a small HDTV in
portland.)

Tell you what: here's the unfinished dmesg patch. I will probably never
look at it again. The theory was to have both the old and new APIs
extract a line at a time from their input and then submit it to a common
codepath that would color it appropriately upon output, that way the old
and new APIs would use 90% the same code.

And since you basically did a complete rewrite of dmesg that I haven't
had a chance to do the design changes I want on: I'm putting it back
into pending. (Not that this matters much to Android's build...)

Rob

P.S. If you can think of a way to implement tests/dmesg.test I'm all
ears. Even with the mkroot stuff, making that reproducible is tricksy.

P.P.S. An advantage of a --color command line option is I can test
colored output without having to write a program that implements its own
pseudo-terminal to collect the output.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abandoned.patch
Type: text/x-diff
Size: 4933 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20170220/9e1b2c8f/attachment.patch>