Linus Torvalds ismét markáns véleményt fogalmazott meg a Linux kernel fejlesztési folyamatairól. Miután a napokban elutasította a RISC-V big endian támogatás ötletét, most a Linux 6.18-hoz beküldött DRM (Direct Rendering Manager) pull request kapcsán fejtette ki elégedetlenségét a kód- és szövegformázással kapcsolatban. A beküldött változtatások kapcsán Torvalds először a szöveg rendezetlenségét bírálta:

• Több alrendszer (Alloc, DMA/Scatterlist, DRM, Rust) leírása véletlenszerű összevisszaságban jelent meg.
• Az indentálás hiányos volt, mintha „egy törött szövegszerkesztő” tette volna tönkre a struktúrát.
• Torvalds ironikusan az őskori EDLIN szerkesztőt említette, amely még a korai PC DOS / MS-DOS rendszerekben szerepelt.
• A fő üzenete egyértelmű volt: a változtatások magyarázata legyen olvasható, logikusan tagolt és strukturált.

A Rust kódformázás problémája

A nagyobb hangsúlyt azonban a Rust nyelven írt kód kapta, amely egyre több helyen jelenik meg a kernelben – például a DRM alrendszer új illesztőprogramjaiban. Torvalds kiemelten kritizálta a rustfmtcheck automatikus formázót:

• Ő a use crate::xyz; típusú importokat inkább így szervezi át, hogy átláthatóbb és bővíthetőbb legyen:

  use crate::{
      xyz,
      abc,
  };
  

• A rustfmtcheck viszont ezt visszateszi egy sorba:

  use crate::{xyz, abc};
  

• Torvalds szerint ez rossz döntés a karbantarthatóság szempontjából, mert nehezíti a későbbi módosításokat és konfliktuskezelést.

Idézete jól összefoglalja a problémát:

„Ez az automatizált eszköz rossz döntéseket hoz a kód hosszú távú karbantarthatóságára nézve. Ez az, ami a jövőben megnehezíti az összeolvasztásokat számomra.”

Miről is van szó:

A Rust hivatalos stílusirányelvei („small items” szabály) arra ösztönzik a fejlesztőket, hogy kisebb importokat egy sorban tartsanak. Torvalds viszont úgy látja, hogy a külön sorokban tartott, egyértelmű importok jobban szolgálják a kód átláthatóságát és a későbbi karbantartást. Több kernel-fejlesztő ezért valószínűleg külön soron hagyja a use kernel::xyz; sorokat, pont a rustfmt heurisztikák elkerülése érdekében.

Linus Torvalds üzenete kettős:

Az emberi olvashatóság fontosabb, mint az automatikus eszközök önkényes döntései. A Rust kód formázási szabályai jelenlegi állapotukban nem illeszkednek jól a Linux kernel fejlesztési gyakorlataihoz, ezért vagy szabálymódosításra, vagy kernel-specifikus kivételekre lenne szükség. Ez az eset jól mutatja, hogy a Rust bevezetése a Linux kernelbe nemcsak technikai, hanem kódstílusbeli és kulturális kihívásokat is felvet.

Az eredeti levele itt is olvasható:

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