linux-kernel - Re: [GIT PULL] Kbuild fixes for v6.8-rc3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK7LNARzZ07TX2obHSpCgsC=FPTbLx5J+kPBFUECT+N7V42i5g@mail.gmail.com>
Date: Fri, 2 Feb 2024 08:57:18 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: [GIT PULL] Kbuild fixes for v6.8-rc3

Hi Linus,


On Fri, Feb 2, 2024 at 5:06 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Thu, 1 Feb 2024 at 05:40, Masahiro Yamada <masahiroy@...nel.org> wrote:
> >
> >  - Replace tabs with spaces when followed by conditionals for
> >    future GNU Make versions
>
> This is horrid.
>
> Now, the whole "whitespace type matters" is broken in Make anyway, so
> clearly this is a fundamental make problem, but this commit makes
> things worse by making the tab replacement use eight spaces, so it
> really visually is entirely indistinguishable.
>
> Don't make a 'make' problem worse by not visually distinguishing tabs
> from spaces.
>
> IOW, those "that can't be a tab" cases should have used pretty much
> _anything_ but 8 spaces. Yes on indentation of nested 'if' statements,
> but no on then using something that visually makes no sense.
>
> IOW, those nested if-statements should use perhaps just 2-4 spaces
> instead. That tends to match what we sometimes see in C files too, and
> it is visually very clearly not a tab with the kernel coding rules
> (yes, yes, some people set tabstops to smaller values, that's _their_
> problem).
>
> I've pulled this, but please fix it, and don't make an insane Makefile
> whitespace situation worse.
>
>                 Linus




Personally, I find 4 spaces more comfortable than 2, as the increased
indentation enhances readability.

When we have a build rule inside an if-block, we cannot indent the code.
In such cases, we can add a comment after the closing 'endif' if it
helps improve the readability, just like we often do for preprocessor
conditionals in C files.


So, the best consistency we can achieve is a combination of
"4-space indentation" and "no indentation at all".

I attached a patch to replace tab/8-space indentation.

Probably, there are still unconverted conditionals, but I fixed
all the code blocks touched by commit 82175d1f9430.

Is this your expectation?






-- 
Best Regards
Masahiro Yamada

View attachment "0001-Makefile-replace-tab-8-space-indentation-with-4-spac.patch" of type "text/x-patch" (24924 bytes)