Re: [PATCH -next v7 1/2] rust: clist: Add support to interface with C linked lists

On 2/6/2026 12:13 PM, Danilo Krummrich wrote:

On Fri Feb 6, 2026 at 5:13 PM CET, Gary Guo wrote:

quoted

On Fri Feb 6, 2026 at 4:05 PM GMT, Joel Fernandes wrote:

quoted

On 2/6/2026 10:53 AM, Danilo Krummrich wrote:

quoted

On Fri Feb 6, 2026 at 4:25 PM CET, Gary Guo wrote:

quoted

On Fri Feb 6, 2026 at 12:41 AM GMT, Joel Fernandes wrote:

quoted

diff --git a/drivers/gpu/Kconfig b/drivers/gpu/Kconfig
index 22dd29cd50b5..2c3dec070645 100644
--- a/drivers/gpu/Kconfig
+++ b/drivers/gpu/Kconfig

@@ -1,7 +1,14 @@
 # SPDX-License-Identifier: GPL-2.0
 
+config RUST_CLIST
+	bool
+	depends on RUST
+	help
+	  Rust abstraction for interfacing with C linked lists.

I am not sure if we need extra config entry. This is fully generic so shouldn't
generate any code unless there is an user.

I also don't think we need a Kconfig for this.

In any case, it shouln't be in drivers/gpu/Kconfig.

Fair point, I believe I was having trouble compiling this into the kernel crate
without warnings (I believe if !GPU_BUDDY). I'll try to drop it and see if we
can get rid of it.

If you run into dead code warnings, I think it is fine to just

    #[allow(dead_code, reason = "all users might be cfg-ed out")]

the overhead of just let rustc type-checking this module isn't worth the extra
Kconfig plumbing, I think.

You mean because there are pub(crate) in clist.rs? I don't think the Kconfig
would help with that, nothing prevents people from enabling RUST_CLIST, but none
of the users.

I think he means add the alloc annotation to suppress deadcode warnings and get
rid of the Kconfig?

Besides that, once we have the new build system, the users of CList are likely
in other crates anyways, so I think we should just change things to pub.

I agree with both approaches. Perhaps changing to pub is better to avoid churn
in the future when other crates use it.

-- 
Joel Fernandes