linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zhangjin Wu <falcon@tinylab.org>
To: w@1wt.eu
Cc: arnd@arndb.de, david.laight@aculab.com, falcon@tinylab.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-riscv@lists.infradead.org, thomas@t-8ch.de
Subject: Re: [PATCH v5 06/14] tools/nolibc: arch-*.h: clean up multiple whitespaces
Date: Mon,  3 Jul 2023 22:02:00 +0800	[thread overview]
Message-ID: <20230703140200.499769-1-falcon@tinylab.org> (raw)
In-Reply-To: <20230702184453.GF16233@1wt.eu>

Hi, Willy

> Hi Zhangjin,
> 
> On Wed, Jun 28, 2023 at 09:19:33PM +0800, Zhangjin Wu wrote:
> > To align with Linux code style and let scripts/checkpatch.pl happy, the
> > multiple whitespaces in arch-<ARCH>.h files are cleaned up.
> > 
> > Most of them are modified by these commands automatically:
> > 
> >     $ sed -i -e '/#define my_syscall/,/})/{s/        /\t/g}' tools/include/nolibc/arch-*.h
> >     $ sed -i -e '/#define my_syscall/,/})/{s/ *\\$/\t\\/g}' tools/include/nolibc/arch-*.h
> > 
> > And checked with:
> > 
> >     $ grep '  *\\$' tools/include/nolibc/arch-*.h
> 
> I'm surprised by this one, I never saw checkpatch complain here. For me,
> putting a tab after a non-tab is an error. It makes the code harder to
> edit and re-align, and diffs are harder to read on lines whose lengths
> varies by +/-1 around a multiple of 8 as it makes the post-tab stuff
> zigzag. You made me recheck the coding style file, and there's nothing
> about alignment there, only about indent (and indent uses tabs here).
> There are also other parts which use spaces for alignment (albeit not
> that many), so unless there is a solid reason for changing that, I'd
> rather not do it, as for me it's the exact opposite of a cleanup as it
> will cause me quite some discomfort.
>

Willy, it is not about alignment, just rechecked it, it is code indent
related:

    #32: FILE: tools/include/nolibc/arch-mips.h:160:
    +^I                                                                      \$
    
    ERROR: code indent should use tabs where possible
    #44: FILE: tools/include/nolibc/arch-mips.h:172:
    +^I          "t0", "t1", "t2", "t3", "t4", "t5", "t6", "t7", "t8", "t9"  \$

The first one is here:

	register long _arg6 = (long)(arg6);                                   \
	<--     whitespaces                                                -->\
	__asm__  volatile (                                                   \

And the second one:

		: "memory", "cc", "at", "v1", "hi", "lo",                     \
	<-spaces->"t0", "t1", "t2", "t3", "t4", "t5", "t6", "t7", "t8", "t9"  \

These two lines indent with "one tab + more than 8 whitespaces", the
other lines also have whitespaces code indent, but not more than 8, so,
not reported.

I have tried to replace whitespaces with tabs in the first one, but the first
one can not align with the other lines, so, the current modify method is
applied.

To only touch minimal lines, this may work (reserve the post-whitespaces):

    $ sed -i -e '/^\t*        /{s/        /\t/g}' tools/include/nolibc/arch-*.h

It will only fix up the lines the reported. The cleanup of the post-whitespaces
is not necessary and it does touch too many lines.

Sorry to disturb you with such cleanups, since I have seen the similar
reports when we added the arch-arm.h (for my_syscall6), because the code
style aligns with the others, so, I did touch it, but again encounter
the same issues with arch-mips.h and to avoid the future reports, I
checked the whole arch-xxx.h, and found more such reports, so, we
prepared such a patch.

To be honest, I do prefer post-tabs to whitespaces (less key press, less code
size ;-)), but as you pointed out, post-tabs have more side-effects, we
shouldn't touch them, Thanks.

> > Besides, more multiple whitespaces are cleaned up:
> > 
> > - convert "__asm__  volatile" to "__asm__ volatile"
> 
> I totally agree on this one, it's very likely the result of a mechanical
> change.

Ok, will split it to a standalone patch, one error report one patch.

> 
> > - "foo _num  bar" should be "foo _num bar"
> 
> In theory yes, except that for those where it appears it was only to
> keep all declarations aligned given that this _num was shorter by one
> char than all other local names. Especially when it comes to enumerating
> register names, you definitely want to keep them aligned. It's sufficiently
> difficult to avoid mistakes there, any help for visual check counts.
>

Agree, let's keep it as before.

Thanks,
Zhangjin

> Willy

  reply	other threads:[~2023-07-03 14:02 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-19 15:40 [PATCH v4 00/10] tools/nolibc: add a new syscall helper Zhangjin Wu
2023-06-19 15:41 ` [PATCH v4 01/10] tools/nolibc: sys.h: add a syscall return helper Zhangjin Wu
2023-06-19 15:42 ` [PATCH v4 02/10] tools/nolibc: unistd.h: apply __sysret() helper Zhangjin Wu
2023-06-19 15:44 ` [PATCH v4 03/10] tools/nolibc: sys.h: " Zhangjin Wu
2023-06-19 15:45 ` [PATCH v4 04/10] tools/nolibc: unistd.h: reorder the syscall macros Zhangjin Wu
2023-06-19 15:47 ` [PATCH v4 05/10] tools/nolibc: add missing my_syscall6() for mips Zhangjin Wu
2023-06-19 15:48 ` [PATCH v4 06/10] tools/nolibc: __sysret: support syscalls who return a pointer Zhangjin Wu
2023-06-19 15:51 ` [PATCH v4 07/10] tools/nolibc: clean up mmap() support Zhangjin Wu
2023-06-21 18:48   ` Thomas Weißschuh
2023-06-22 19:08     ` Zhangjin Wu
2023-06-19 15:52 ` [PATCH v4 08/10] selftests/nolibc: add EXPECT_PTREQ, EXPECT_PTRNE and EXPECT_PTRER Zhangjin Wu
2023-06-19 15:54 ` [PATCH v4 09/10] selftests/nolibc: add sbrk_0 to test current brk getting Zhangjin Wu
2023-06-19 15:55 ` [PATCH v4 10/10] selftests/nolibc: add mmap and munmap test cases Zhangjin Wu
2023-06-19 16:14   ` Zhangjin Wu
2023-06-21 18:58   ` Thomas Weißschuh
2023-06-22 19:32     ` Zhangjin Wu
2023-06-22 19:56       ` Thomas Weißschuh
2023-06-24  7:47         ` Zhangjin Wu
2023-06-28 13:07 ` [PATCH v5 00/14] tools/nolibc: add a new syscall helper Zhangjin Wu
2023-06-28 13:08   ` [PATCH v5 01/14] tools/nolibc: sys.h: add a syscall return helper Zhangjin Wu
2023-06-28 13:11   ` [PATCH v5 02/14] tools/nolibc: unistd.h: apply __sysret() helper Zhangjin Wu
2023-06-28 13:13   ` [PATCH v5 03/14] tools/nolibc: sys.h: " Zhangjin Wu
2023-06-28 13:14   ` [PATCH v5 04/14] tools/nolibc: unistd.h: reorder the syscall macros Zhangjin Wu
2023-06-28 13:17   ` [PATCH v5 05/14] tools/nolibc: string.h: clean up multiple whitespaces with tab Zhangjin Wu
2023-06-28 13:19   ` [PATCH v5 06/14] tools/nolibc: arch-*.h: clean up multiple whitespaces Zhangjin Wu
2023-07-02 18:44     ` Willy Tarreau
2023-07-03 14:02       ` Zhangjin Wu [this message]
2023-06-28 13:22   ` [PATCH v5 07/14] tools/nolibc: arch-loongarch.h: shrink with SYSCALL_CLOBBERLIST Zhangjin Wu
2023-07-02 18:50     ` Willy Tarreau
2023-07-03 11:28       ` Zhangjin Wu
2023-06-28 13:31   ` [PATCH v5 08/14] tools/nolibc: arch-mips.h: " Zhangjin Wu
2023-06-28 13:37   ` [PATCH v5 09/14] tools/nolibc: add missing my_syscall6() for mips Zhangjin Wu
2023-07-02 18:55     ` Willy Tarreau
2023-07-03 10:13       ` Zhangjin Wu
2023-06-28 13:39   ` [PATCH v5 10/14] tools/nolibc: __sysret: support syscalls who return a pointer Zhangjin Wu
2023-07-02 19:17     ` Willy Tarreau
2023-07-03  8:36       ` Zhangjin Wu
2023-07-03 10:03         ` Willy Tarreau
2023-07-03 11:15           ` Zhangjin Wu
2023-06-28 13:41   ` [PATCH v5 11/14] tools/nolibc: clean up mmap() support Zhangjin Wu
2023-07-02 19:23     ` Willy Tarreau
2023-07-03  6:51       ` Zhangjin Wu
2023-06-28 13:44   ` [PATCH v5 12/14] selftests/nolibc: add EXPECT_PTREQ, EXPECT_PTRNE and EXPECT_PTRER Zhangjin Wu
2023-06-28 13:46   ` [PATCH v5 13/14] selftests/nolibc: add sbrk_0 to test current brk getting Zhangjin Wu
2023-06-28 13:51   ` [PATCH v5 14/14] selftests/nolibc: add mmap and munmap test cases Zhangjin Wu
2023-07-02 19:33     ` Willy Tarreau
2023-07-03  6:03       ` Zhangjin Wu
2023-07-03  7:25         ` Willy Tarreau
2023-07-03  8:06           ` Zhangjin Wu
2023-07-03  8:20             ` Thomas Weißschuh
2023-07-03  9:15               ` Zhangjin Wu
2023-07-03  9:56             ` Willy Tarreau
2023-07-03 11:24               ` Zhangjin Wu
2023-07-02 19:34   ` [PATCH v5 00/14] tools/nolibc: add a new syscall helper Willy Tarreau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230703140200.499769-1-falcon@tinylab.org \
    --to=falcon@tinylab.org \
    --cc=arnd@arndb.de \
    --cc=david.laight@aculab.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=thomas@t-8ch.de \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).