linux-kernel - Re: [PATCH v2 2/2] scripts: generate_rust

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] [day] [month] [year] [list]

Message-ID: <CAJ-ks9=Fqnb+daWoGStbeHZFY0nqe9jkufF=drGac8xsXY9Yyg@mail.gmail.com>
Date: Thu, 22 Jan 2026 10:09:28 -0500
From: Tamir Duberstein <tamird@...nel.org>
To: Jesung Yang <y.j3ms.n@...il.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, 
	Danilo Krummrich <dakr@...nel.org>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Nathan Chancellor <nathan@...nel.org>, 
	Nicolas Schier <nsc@...nel.org>, Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] scripts: generate_rust_analyzer.py: reduce cfg plumbing

On Wed, Jan 21, 2026 at 6:12 PM Jesung Yang <y.j3ms.n@...il.com> wrote:
>
> On Wed Jan 21, 2026 at 11:13 PM KST, Tamir Duberstein wrote:
> > On Tue, Jan 20, 2026 at 8:16 PM Jesung Yang <y.j3ms.n@...il.com> wrote:
> >> On Wed Jan 21, 2026 at 1:10 AM KST, Tamir Duberstein wrote:
> >> > Centralize `cfg` lookup in `append_crate` to avoid having to do so for
> >> > each crate. Remove hardcoded `cfg`s for `pin-init{,-internal}` now that
> >> > these are passed from `rust/Makefile`.
> >> >
> >> > Signed-off-by: Tamir Duberstein <tamird@...nel.org>
> >> > ---
> >> >  scripts/generate_rust_analyzer.py | 13 +++++--------
> >> >  1 file changed, 5 insertions(+), 8 deletions(-)
> >> >
> >> > diff --git a/scripts/generate_rust_analyzer.py b/scripts/generate_rust_analyzer.py
> >> > index 147d0cc94068..b96d3cbe3df1 100755
> >> > --- a/scripts/generate_rust_analyzer.py
> >> > +++ b/scripts/generate_rust_analyzer.py
> >> > @@ -35,7 +35,9 @@ def generate_crates(srctree, objtree, sysroot_src, external_src, cfgs, core_edit
> >> >      crates_indexes = {}
> >> >      crates_cfgs = args_crates_cfgs(cfgs)
> >> >
> >> > -    def append_crate(display_name, root_module, deps, cfg=[], is_workspace_member=True, is_proc_macro=False, edition="2021"):
> >> > +    def append_crate(display_name, root_module, deps, cfg=None, is_workspace_member=True, is_proc_macro=False, edition="2021"):
> >> > +        if cfg is None:
> >> > +            cfg = crates_cfgs.get(display_name, [])
> >>
> >> Could we add a brief comment explaining how the behavior of
> >> `append_crate` changes according to the `cfg` parameter? Since `None`
> >> and an empty list have different effects, documenting that distinction
> >> would make the intended behavior clearer.
> >
> > I don't think this is necessary - it won't age well when we change the
> > entire API surface here in the next version of the series[0] that adds
> > type annotations.
> >
> > Link: https://lore.kernel.org/all/20250424-rust-analyzer-host-v6-0-40e67fe5c38a@gmail.com/
> > [0]
> >
> >> This would also help later when we add proper Python docstrings.
> >
> > Same as above: a lot of change is coming. Is this worth considering right now?
>
> Fair point, thanks for the context.
>
> Reviewed-by: Jesung Yang <y.j3ms.n@...il.com>
>
> By the way, could you share your plan for upcoming major changes? It
> would help me prepare and align my series if I know the intended
> direction. I currently have these on my radar:
>
>   [1] https://lore.kernel.org/all/20250424-rust-analyzer-host-v6-0-40e67fe5c38a@gmail.com/
>   [2] https://lore.kernel.org/rust-for-linux/20260109-ra-fix-primitive-v2-0-249852a4145a@gmail.com/
>   [3] https://lore.kernel.org/rust-for-linux/20260120-ra-fix-v1-0-829e4e92818c@nvidia.com/
>
> I assume you would prefer merging [1] first? Please let me know if I'm
> missing something.

Yeah, these are the big changes I'm currently aware of. I'm going to
look for ways to split [1] into smaller parts. The main thing I'd like
to get in ASAP is type annotations as maintenance becomes much easier
following that.

>
> Thanks!
>
> Best regards,
> Jesung