Generate rust-project.json entries for scripts written in Rust.

Use `Pathlib.path.stem` for consistency.

Fixes: 9a8ff24ce584 ("scripts: add `generate_rust_target.rs`")
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Fiona Behrens <me@kloenk.dev>
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Signed-off-by: Tamir Duberstein <tamird@kernel.org>
---
 scripts/generate_rust_analyzer.py | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/scripts/generate_rust_analyzer.py b/scripts/generate_rust_analyzer.py
index 3b645da90092..650535f2228d 100755
--- a/scripts/generate_rust_analyzer.py
+++ b/scripts/generate_rust_analyzer.py
@@ -188,6 +188,18 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, core_edit
     append_crate_with_generated("uapi", ["core", "ffi", "pin_init"])
     append_crate_with_generated("kernel", ["core", "macros", "build_error", "pin_init", "ffi", "bindings", "uapi"])
 
+    scripts = srctree / "scripts"
+    makefile = (scripts / "Makefile").read_text()
+    for path in scripts.glob("*.rs"):
+        name = path.stem
+        if f"{name}-rust" not in makefile:
+            continue
+        append_crate(
+            name,
+            path,
+            deps=["std"],
+        )
+
     def is_root_crate(build_file, target):
         try:
             return f"{target}.o" in open(build_file).read()
@@ -203,7 +215,7 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, core_edit
     for folder in extra_dirs:
         for path in folder.rglob("*.rs"):
             logging.info("Checking %s", path)
-            name = path.name.replace(".rs", "")
+            name = path.stem
 
             # Skip those that are not crate roots.
             if not is_root_crate(path.parent / "Makefile", name) and \

---
base-commit: 2af6ad09fc7dfe9b3610100983cccf16998bf34d
change-id: 20260122-rust-analyzer-scripts-39e673a918ff

Best regards,
--  
Tamir Duberstein <tamird@kernel.org>

On Thu, Jan 22, 2026 at 5:53 PM Tamir Duberstein <tamird@kernel.org> wrote:
>
> Generate rust-project.json entries for scripts written in Rust.
>
> Use `Pathlib.path.stem` for consistency.
>
> Fixes: 9a8ff24ce584 ("scripts: add `generate_rust_target.rs`")
> Cc: stable@vger.kernel.org
> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
> Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
> Reviewed-by: Fiona Behrens <me@kloenk.dev>
> Reviewed-by: Trevor Gross <tmgross@umich.edu>
> Signed-off-by: Tamir Duberstein <tamird@kernel.org>

Hmm... This introduces support for scripts, right? i.e. it is a
feature, or am I misunderstanding the Fixes:/Cc: stable tags?

Also, I don't see the Tested-by from Daniel -- he gave it on the last
patch in v4, but not this one. Was it because it was assumed that
testing the last patch meant testing all? Generally that shouldn't be
assumed, e.g. he gave two Tested-by tags, so I guess he didn't mean to
give it to all.

I would also suggest on apply to give it a bit more details.

Anyway, this seems best suited for rust-analyzer-next after the merge
window when the above is sorted out.

Thanks for reviving these patches and splitting them!

Cheers,
Miguel

On Sun, Jan 25, 2026 at 9:09 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Thu, Jan 22, 2026 at 5:53 PM Tamir Duberstein <tamird@kernel.org> wrote:
> >
> > Generate rust-project.json entries for scripts written in Rust.
> >
> > Use `Pathlib.path.stem` for consistency.
> >
> > Fixes: 9a8ff24ce584 ("scripts: add `generate_rust_target.rs`")
> > Cc: stable@vger.kernel.org
> > Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
> > Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
> > Reviewed-by: Fiona Behrens <me@kloenk.dev>
> > Reviewed-by: Trevor Gross <tmgross@umich.edu>
> > Signed-off-by: Tamir Duberstein <tamird@kernel.org>
>
> Hmm... This introduces support for scripts, right? i.e. it is a
> feature, or am I misunderstanding the Fixes:/Cc: stable tags?

It depends on your perspective - I framed it as a fix of the commit
that added the first script because that script was added without RA
support. What do you think?

> Also, I don't see the Tested-by from Daniel -- he gave it on the last
> patch in v4, but not this one. Was it because it was assumed that
> testing the last patch meant testing all? Generally that shouldn't be
> assumed, e.g. he gave two Tested-by tags, so I guess he didn't mean to
> give it to all.

It was so long ago, I'm not sure. I'll remove the tag. Thanks for calling out!

> I would also suggest on apply to give it a bit more details.
>
> Anyway, this seems best suited for rust-analyzer-next after the merge
> window when the above is sorted out.

Will do.

>
> Thanks for reviving these patches and splitting them!
>
> Cheers,
> Miguel
>

On Tue, Jan 27, 2026 at 2:53 PM Tamir Duberstein <tamird@kernel.org> wrote:
>
> It depends on your perspective - I framed it as a fix of the commit
> that added the first script because that script was added without RA
> support. What do you think?

Yeah, I see.

So, on the implementation side, I don't think we expected scripts to
work at all, which is why it sounds to me like a feature (neither the
linked commit nor the one that added rust-analyzer overall support
mentions it that I can see, though it doesn't say otherwise either).

But perhaps someone out there expected it to actually work and thus
may think of it as a fix. I don't recall someone asking for it, but I
haven't checked. Perhaps someone would, when we use more and more Rust
scripts.

Now, for the backport part, according to the official rules, I think
it wouldn't fit. But those rules are often relaxed and who knows what
companies out there doing out-of-tree work on top of LTS kernels
want... (Commits can be submitted there even if they are not fixes, by
the way).

Cheers,
Miguel

On Tue, Jan 27, 2026 at 10:13 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Tue, Jan 27, 2026 at 2:53 PM Tamir Duberstein <tamird@kernel.org> wrote:
> >
> > It depends on your perspective - I framed it as a fix of the commit
> > that added the first script because that script was added without RA
> > support. What do you think?
>
> Yeah, I see.
>
> So, on the implementation side, I don't think we expected scripts to
> work at all, which is why it sounds to me like a feature (neither the
> linked commit nor the one that added rust-analyzer overall support
> mentions it that I can see, though it doesn't say otherwise either).
>
> But perhaps someone out there expected it to actually work and thus
> may think of it as a fix. I don't recall someone asking for it, but I
> haven't checked. Perhaps someone would, when we use more and more Rust
> scripts.
>
> Now, for the backport part, according to the official rules, I think
> it wouldn't fit. But those rules are often relaxed and who knows what
> companies out there doing out-of-tree work on top of LTS kernels
> want... (Commits can be submitted there even if they are not fixes, by
> the way).

Thanks for the context. In that case I'll keep it as a fix and take it
through rust-analyzer-next with the backport tags since I expect it to
apply cleanly.

Cheers,
Tamir

On Tue, Jan 27, 2026 at 12:07 PM Tamir Duberstein <tamird@kernel.org> wrote:
>
> On Tue, Jan 27, 2026 at 10:13 AM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> > On Tue, Jan 27, 2026 at 2:53 PM Tamir Duberstein <tamird@kernel.org> wrote:
> > >
> > > It depends on your perspective - I framed it as a fix of the commit
> > > that added the first script because that script was added without RA
> > > support. What do you think?
> >
> > Yeah, I see.
> >
> > So, on the implementation side, I don't think we expected scripts to
> > work at all, which is why it sounds to me like a feature (neither the
> > linked commit nor the one that added rust-analyzer overall support
> > mentions it that I can see, though it doesn't say otherwise either).
> >
> > But perhaps someone out there expected it to actually work and thus
> > may think of it as a fix. I don't recall someone asking for it, but I
> > haven't checked. Perhaps someone would, when we use more and more Rust
> > scripts.
> >
> > Now, for the backport part, according to the official rules, I think
> > it wouldn't fit. But those rules are often relaxed and who knows what
> > companies out there doing out-of-tree work on top of LTS kernels
> > want... (Commits can be submitted there even if they are not fixes, by
> > the way).
>
> Thanks for the context. In that case I'll keep it as a fix and take it
> through rust-analyzer-next with the backport tags since I expect it to
> apply cleanly.
>
> Cheers,
> Tamir

Applied to rust-analyzer-next. Thanks all!

On Fri, Jan 30, 2026 at 9:15 PM Tamir Duberstein <tamird@kernel.org> wrote:
>
> Applied to rust-analyzer-next. Thanks all!

Please see the other thread (and please reset the branch to e.g.
v6.19-rc7 for now -- we should avoid giving linux-next unneeded
conflicts).

Cheers,
Miguel

On Fri, Jan 30, 2026 at 3:23 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Fri, Jan 30, 2026 at 9:15 PM Tamir Duberstein <tamird@kernel.org> wrote:
> >
> > Applied to rust-analyzer-next. Thanks all!
>
> Please see the other thread (and please reset the branch to e.g.
> v6.19-rc7 for now -- we should avoid giving linux-next unneeded
> conflicts).

Ack, done.