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

[enh]

On Mon, Feb 20, 2017 at 7:48 PM, Rob Landley <rob at landley.net> wrote:

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

(fixed in the dmesg -T patch i sent a couple of days ago.)


> 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.
>
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
>


-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20170329/93a08289/attachment.htm>