linux-kernel - Re: [PATCH] editorconfig: Add automatic editor configuration file

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]

Date:   Fri, 3 Jul 2020 09:49:37 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Danny Lin <danny@...ag0n.dev>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Andy Whitcroft <apw@...onical.com>,
        Joe Perches <joe@...ches.com>,
        Jonathan Corbet <corbet@....net>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] editorconfig: Add automatic editor configuration file

On Fri, Jul 3, 2020 at 9:31 AM Danny Lin <danny@...ag0n.dev> wrote:
>
> Most of the other exceptions can be accomodated for with more specific
> rules below the base [*] section. I just went through most of the
> kernel's files and added rules for the vast majority of the exceptinos
> to the 8-column tab indent style, though there are still some that
> haven't been covered.

Very good! That looks much better.

Are there too many file types that use tabs? If not, then I think it
is best to add a section for "General tab" files like for the others,
in order to be explicit and to have the list around.

> It looks like some types of files lack consistent indentation, e.g.
> arch/mips/*/Platform and some shell scripts in scripts/ tools/testing/
> selftests/ftrace/test.d/kprobe/*.tc. There are also some files that were
> highly inconsistent even within themselves (e.g. drivers/gpu/drm/amd/
> amdkfd/cwsr_trap_handler_gfx*.asm), so setting indentation settings to
> something sane by default doesn't make them any worse. After all, no
> automated code style tooling is perfect and there will be edge cases
> where it breaks down.

Yeah, do not worry about inconsistencies. For `.clang-format`, I
picked the options based on 1) whether there was an official code
style guideline and 2) if not, the one that minimizes the number of
changes, i.e. the most popular one across files.

Cheers,
Miguel