linux-kernel - Re: [git pull] drm for 6.18-rc1

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: <CANiq72kq5YHovH=_a9c0JQgfrAx9gRsQvVo1VfHd-FaupOp7rQ@mail.gmail.com>
Date: Thu, 2 Oct 2025 23:04:34 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Dave Airlie <airlied@...il.com>, Miguel Ojeda <ojeda@...nel.org>, Sima Vetter <sima@...ll.ch>, 
	dri-devel <dri-devel@...ts.freedesktop.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm for 6.18-rc1

On Thu, Oct 2, 2025 at 9:54 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Miguel, I know you asked me to run rustfmtcheck, but that thing is
> just WRONG. It may be right "in the moment", but it is
>
>  (a) really annoying when merging and not knowing what the heck the rules are
>
>  (b) it's bad long term when you don't have clean lists of "add one
> line for a new use"
>
> Is there some *sane* solution to this? Because I left my resolution
> alone and ignored the horrible rustfmtcheck results.

We have discussed `use` statements formatting somewhat recently
because of that (and rebasing patches etc.). `rustfmt` allows to be
configured -- it has a few knobs for this that we are considering:

    https://rust-lang.github.io/rustfmt/

e.g. the `imports_layout`, `imports_granularity`, `group_imports` --
some people like the braces, others the one per line, etc.

Sadly, those related options are unstable (and nightly-only), but I
can talk to upstream to see what can be done (so your opinions on this
matter would help).

In any case, for you, my intention wasn't that you had to fight the
formatting, but rather that after solving the conflict (without
thinking about formatting) you would run `make ... rustfmt`, i.e.
instead of the other one, `rustfmtcheck` (which is intended for e.g.
CIs).

Leaving non-formatted files does hurt us, though... e.g. CIs check it,
and I think people are generally happy about the simplicity of
formatting on the Rust side.

So if the conflicts are already too frequent and/or painful to deal
with, then I would say we should already start writing the imports in
a way that reduces the conflict potential, yet making it pass
`rustfmt`. It may be uglier than what some may like (depending on who
one asks), but it keeps the `rustfmt`-clean property and eventually we
may be able to get `rustfmt` to give us the formatting we want and
migrate to that.

Cheers,
Miguel