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: <CANiq72kDB1cX1XXX7sc3yQvnaUUYB8q1wVKNxykv8=OV-=rWuQ@mail.gmail.com>
Date: Tue, 7 Oct 2025 19:21:13 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Maarten ter Huurne <maarten@...ewalker.org>, John Hubbard <jhubbard@...dia.com>, 
	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 Sun, Oct 5, 2025 at 11:33 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Oh, that sounds like a good heuristic, because that "comma after last
> entry" is very much "I expect this list to be expanded upon later".

We can use a trick today to approximate that, which is adding a
comment after one of the commas, e.g.

    use crate::{
        fmt,
        page::AsPageIter, //
    };

It is not the first time I do something like that -- I used an empty
comment to force visual separation between attributes in b9b701fce49a
("rust: clarify the language unstable features in use"), so there is
some precedent.

Yes, it isn't ideal, but it avoids the repetition of the prefix all
the time (many `use` statements), and we can use that temporarily as a
shorthand for "skip formatting this" (which `rustfmt` also supports
with an attribute, but takes more characters and a new line). Then, if
upstream `rustfmt` agrees, eventually we should be able to remove
those extra couple slashes and everything should "just work", i.e.
stay the same.

It seems to work fine in the nested cases (i.e. you can control it
per-level), and it allows to keep single item cases with braces too.

So I will send you a patch to unbreak the situation with some added
docs too, unless you hate it.

By the way, I also took a very quick look at the "trailing comma" idea
to see how complex it could be upstream (it could be either a "just
accept the multiline formatting if there is a trailing comma" approach
or the "take the comma as a hint to reformat accordingly" one
mentioned), and it seems doable. But we will see what they think about
it -- they don't have much bandwidth, I think.

I ran a quick test for the reformatting approach on the kernel, and
the diff isn't terribly big (e.g. +183 -45). One gets things like [1]
-- notice how the nested one (`property::`) is kept as a one liner
because there is no comma there, but the others are reformatted as
vertical on purpose. And if one adds a comma after `NArgs`, then it
will make it multiline.

If we got something like this upstream, it should be easy to
eventually migrate since the diff can be kept small by using the
workaround above meanwhile.

Cheers,
Miguel

[1]

diff --git a/samples/rust/rust_driver_platform.rs
b/samples/rust/rust_driver_platform.rs
index 6473baf4f120..90544b093c85 100644
--- a/samples/rust/rust_driver_platform.rs
+++ b/samples/rust/rust_driver_platform.rs
@@ -63,13 +63,15 @@
 //!

 use kernel::{
-    acpi, c_str,
+    acpi,
+    c_str,
     device::{
         self,
         property::{FwNodeReferenceArgs, NArgs},
         Core,
     },
-    of, platform,
+    of,
+    platform,
     prelude::*,
     str::CString,
     sync::aref::ARef,