Message-ID: <CAHk-=wgO7S_FZUSBbngG5vtejWOpzDfTTBkVvP3_yjJmFddbzA@mail.gmail.com>
Date: Thu, 2 Oct 2025 12:53:45 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Dave Airlie <airlied@...il.com>, Miguel Ojeda <ojeda@...nel.org>
Cc: 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

[ Miguel: Rust conflict resolution question at the end ]

On Tue, 30 Sept 2025 at 21:06, Dave Airlie <airlied@...il.com> wrote:
>
> As usual, let me know if there are any problems.

You are still corrupting indentation in your explanations.

I don't know *what* you are doing wrong, but it's wrong. You seem to
have lost all indentation.

Look here as an example:

> rust:
> - drop Opaque<> from ioctl args
> - Alloc:
> - BorrowedPage type and AsPageIter traits
> - Implement Vmalloc::to_page() and VmallocPageIter
> - DMA/Scatterlist:
> - Add dma::DataDirection and type alias for dma_addr_t
> - Abstraction for struct scatterlist and sg_table
> - DRM:
> - simplify use of generics
> - add DriverFile type alias
> - drop Object::SIZE
> - Rust:
> - pin-init tree merge
> - Various methods for AsBytes and FromBytes traits

Notice how there are multiple sub-areas: Alloc, DMA/Scatterlist, DRM and Rust.

But it's all just a random jumble, because you have apparently pasted
it into your editor or MUA or whatever and dropped the indentation in
the process.

Or something.

What kind of *broken* editor are you using? I'm not trying to start an
emacs or vi war here, but you seem to be using something truly broken.

EDLIN?

And similar thing here:

> msm:
> - GPU and Core:
> - in DT bindings describe clocks per GPU type
> - GMU bandwidth voting for x1-85
> - a623/a663 speedbins
> - cleanup some remaining no-iommu leftovers after VM_BIND conversion
> - fix GEM obj 32b size truncation
> - add missing VM_BIND param validation
> - IFPC for x1-85 and a750
> - register xml and gen_header.py sync from mesa
> - Display:
> - add missing bindings for display on SC8180X
> - added DisplayPort MST bindings
> - conversion from round_rate() to determine_rate()

Look, again, no logic and you've completely corrupted any multi-level
indentation that presumably existed at some point judging by the
organization.

WTH?

I try to make this all legible as I walk through it myself.

So I regularly fix up peoples language skills etc, because I
understand that English isn't always the native language (and that
even if it is, some people just aren't very good at writing
explanations).

But these kinds of "I'm pretty sure you've just corrupted the
formatting that was there in some original message" is just
_annoying_.

Please make the explanations *readable*, not just a random jumble of words.

And on a more technical side: I absolutely detest the mindless and
completely crazy Rust format checking.

I noticed that people added multiple

  use crate::xyz;

next to each other, so I turned them into

  use crate::{
     xyz,
    abc,
  };

instead to make it easy to just add another crate without messing crap
up. The use statements around it had that format too, so it all seemed
sensible and visually consistent.

But then I run rustfmtcheck, and that thing is all bass-ackwards
garbage. Instead of making it clean and clear to add new rules, it
suggests

  use crate::{xyz, abc};

but I have no idea what the heuristics for when to use multiple lines
and when to use that compressed format are.

This is just ANNOYING. It's automated tooling that is literally making
bad decisions for the maintainability. This is the kind of thing that
makes future conflicts harder for me to deal with.

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.

I tried to google the rust format rules, and apparently it's this:

    https://doc.rust-lang.org/style-guide/index.html#small-items

can we please fix up whatever random heuristics? That small items
thing may make sense when we're talking things that really are one
common data structure, but the "use" directive is literally about
*independent* things that get used, and smushing them all together
seems entirely wrong.

I realize that a number of users seem to just leave the repeated

   use kernel::xyz;
   use kernel::abc;

as separate lines, possibly *becasue* of this horrendous rustfmt
random heuristic behavior.

              Linus

Powered by blists - more mailing lists