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: <CANiq72koDba445gMYtC_VEcFk2+O-Xg2-2y6uMyp7onBy=7rcw@mail.gmail.com>
Date: Tue, 4 Mar 2025 22:00:06 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Guilherme Giacomo Simoes <trintaeoitogc@...il.com>
Cc: a.hindborg@...nel.org, 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

On Tue, Mar 4, 2025 at 9:51 PM Guilherme Giacomo Simoes
<trintaeoitogc@...il.com> wrote:
>
> hostprog like rustfmt?

No, Andreas means a script written in Rust, rather than a binary that
comes from the toolchain.

I think it could be a good idea (it would be lovely to write the
checker in Rust -- I also had a checker bot in Python from the old
days of the old `rust` branch in GitHub), but `checkpatch.pl` doesn't
need a built kernel, so it would be a disadvantage or at least a
difference w.r.t. the usual `checkpatch.pl`, and we may not be able to
call it from `checkpatch.pl`.

> About this, Daniel Sedlak say:
> "I think we could fight with the code formatting, because when it comes
> to the rust macros, rustfmt is often very confused and we could end up
> with variations like:

Did you check? i.e. is it something we noticed, or something that
generally happens but maybe not in this case? Is there a way to
workaround or disable that (e.g. a `rustfmt` config value)?

Thanks!

Cheers,
Miguel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ