linux-kernel - Re: [PATCH master] module: remove never implemented MODULE_SUPPORTED

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: <CAHk-=wjZoOr4yqAAxricTsachacAUvcKt6HOfxyReCyMN0V=QQ@mail.gmail.com>
Date:   Thu, 18 Mar 2021 10:55:51 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH master] module: remove never implemented MODULE_SUPPORTED_DEVICE

On Thu, Mar 18, 2021 at 10:49 AM Leon Romanovsky <leon@...nel.org> wrote:
>
> No, I opened patch and added the note manually, so it is definitely my VIM.
> Most likely this part of my .vimrc caused it.

Ok, that would do it.

Yeah, whitespace is easy to "fix" at patch application time, but it
really is meaningful and you never should change whitespace for
patches.

Maybe you can limit your rules to just particular file types
(although, honestly, I think it's bad for headers and C files too when
it then causes entirely irrelevant and independent changes - you only
want your own _new_ edits to be whitespace-clean, not fix other random
issues).

Better yet, maybe not "fix whitespace" at all, but have some code
coloring logic that just points out bad whitespace? I use "git diff"
myself, with colorization being default for tty operations:

    [color]
        ui=auto

so that then "git diff" will show you your (new) evil whitespace
errors when you review your changes, but won't complain about existing
whitespace issues..

                      Linus