Message-ID: <CAPM=9txjNo==nMA7XcjzLWLO155+1bk2THwPs_BmTLu_5kU_bQ@mail.gmail.com>
Date: Fri, 3 Oct 2025 20:52:58 +1000
From: Dave Airlie <airlied@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: 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 Fri, 3 Oct 2025 at 05:54, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> [ 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.

I do that on purpose. there are Alloc: to show. Think C no python :-)

I get about 15-20 pull requests in various formats from very different
groups of people, if I just cut-n-paste them all into the changelog it
would be horribly inconsistent.

I try to harmonize them for myself, so they are somewhat visually
consistent, i.e. single level of indenting is my limit.

I can keep all the crazy if you feel it's valuable, for me it's just
different forms of the same information.

I'll let Miguel deal with rustfmt.

Dave.

>
> 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