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

enh enh at google.com
Wed Jan 4 13:46:03 PST 2017


On Wed, Jan 4, 2017 at 1:28 PM, Rob Landley <rob at landley.net> wrote:
> On 01/04/2017 01:08 PM, enh wrote:
>> I never use these, so I didn't notice I'd broken them until someone who
>> does bringup complained.
>
> Er...
>
> $ git diff toys/*/dmesg.c | diffstat
>  dmesg.c |   73
> +++++++++++++++++++++++++++++++++-------------------------------
>  1 file changed, 38 insertions(+), 35 deletions(-)
>
> I'm in the process of redoing that entire file. But I'll take a look.
>
> Alas, all of that was done during my trip to San Diego and I haven't had
> a chance to look at it since. Seriously, the _second_ biggest downside
> of the constant interruptions breaking my development time into small
> chunks with large gaps between them is I do 2/3 of something and then
> come back and spend that much time/effort _again_ working out what I
> already did and what I haven't done yet and why I was doing it. Half the
> time I just throw out my local changes start over so I'll at least know
> where I _am_, but after the third time you do that to something like
> "dd" you lose all mental model of what the code _currently_ looks like
> and what didn't get saved, and what you didn't do because it turned out
> to be bad idea and what you didn't do because you just got interrupted
> multiple times before you could finish, test, and check it in. Sigh...
> This is why my current work directory is "toybox/toy3", because
> toybox/toybox and toybox/toy2 have piles of unifinished commits against
> a now-stale version until I just started making changes in a clean
> directory. And of course toy3 is:
>
> $ git diff | diffstat | tail -n 1
>  33 files changed, 467 insertions(+), 427 deletions(-)
>
>> The "one weird trick" with SEEK_DATA is documented at the URL we already
>> point to. SEEK_DATA was added in Linux 3.1 (2011) and isn't available in
>> glibc 2.19 (2014), so I've added that to "portability.h" for the benefit
>> of Ubuntu 14.04.
>
> Another half-finished thing I have in my tree is xsendfile_sparse(), so
> oddly enough I've already got a local patch adding that. :)
>
> (Because initramfs can't do xattrs unless cpio can store them, and as
> long as we're proposing a change to the cpio format it should do 64 bit
> timestamps with nanoseconds and handle sparse files. I've restarted work
> on that ~3 times now...)
>
> Speaking of portability.h, I've pretty much given up on uClibc
> (http://lists.busybox.net/pipermail/buildroot/2016-December/180102.html)
> and am trying to figure out if I should remove the uClibc portability.h
> bits or leave it there. I should probably check if buildroot's uClibc-ng
> works without them, but I haven't had a chance to spend time on it yet...
>
>> Also make -c and -C mutually exclusive.
>>
>> Also fix some of the formatting I introduced earlier. (A clang-format file
>> would help prevent these mistakes...)
>
> I dunno clang-format. Is it similar to lindent?
>
>   https://github.com/torvalds/linux/blob/master/scripts/Lindent
>   https://www.freebsd.org/cgi/man.cgi?query=indent
>
> (This is a thing I'm aware of, but have not personally found useful.
> Fixing up whitespace is one of the things I do during cleanup passes. :)

no, http://clang.llvm.org/docs/ClangFormat.html is a source
reformatter based on the clang parser. if your project adheres to
chromium style, say, you just say --style=Chromium and it means
changes look the same, no matter who submits them. you can have a
.clang-format file in your project to configure the formatting to
whatever your project's style actually is
(http://clang.llvm.org/docs/ClangFormatStyleOptions.html). certainly
means contributors don't have to think "would rob have spaces here or
not?".

> Thanks for the patch, I'll try to take a look this evening,
>
> Rob



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



More information about the Toybox mailing list