linux-kernel - Re: [PATCH V6 2/2] checkpatch: check format of Vec<String> in modules

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: <87ldtjenv5.fsf@kernel.org>
Date: Wed, 05 Mar 2025 12:08:30 +0100
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Miguel Ojeda" <miguel.ojeda.sandonis@...il.com>
Cc: "Guilherme Giacomo Simoes" <trintaeoitogc@...il.com>,
  <alex.gaynor@...il.com>,  <aliceryhl@...gle.com>,  <apw@...onical.com>,
  <arnd@...db.de>,  <aswinunni01@...il.com>,  <axboe@...nel.dk>,
  <benno.lossin@...ton.me>,  <bhelgaas@...gle.com>,
  <bjorn3_gh@...tonmail.com>,  <boqun.feng@...il.com>,  <dakr@...nel.org>,
  <dwaipayanray1@...il.com>,  <ethan.twardy@...il.com>,
  <fujita.tomonori@...il.com>,  <gary@...yguo.net>,
  <gregkh@...uxfoundation.org>,  <joe@...ches.com>,
  <linux-kernel@...r.kernel.org>,  <lukas.bulwahn@...il.com>,
  <ojeda@...nel.org>,  <pbonzini@...hat.com>,
  <rust-for-linux@...r.kernel.org>,  <tmgross@...ch.edu>,
  <walmeida@...rosoft.com>
Subject: Re: [PATCH V6 2/2] checkpatch: check format of Vec<String> in modules

"Miguel Ojeda" <miguel.ojeda.sandonis@...il.com> writes:

> On Wed, Mar 5, 2025 at 8:53 AM Andreas Hindborg <a.hindborg@...nel.org> wrote:
>>
>> Right, it needs a bit more tool support than running checkpatch.pl
>> needs. Perhaps we could move it from checkpatch.pl to the rustfmt make
>> target?
>
> That could perhaps be an option for this case, though not sure if it
> applies to all cases, i.e. `checkpatch.pl` also checks things that
> only make sense to check in a patch and also things that are not
> related to formatting.
>
> Perhaps we want an entirely separate thing in `tools/` eventually, or
> even out of the kernel tree, so that it can be easily run as a bot
> etc. like in the past.
>
> In any case, landing checks here is fine (as long as Joe et al.
> agree), they can be moved or removed later if needed.

Absolutely. Just brainstorming at this point.


Best regards,
Andreas Hindborg