On Fri Feb 6, 2026 at 5:13 PM CET, Gary Guo wrote: > On Fri Feb 6, 2026 at 4:05 PM GMT, Joel Fernandes wrote: >> >> >> On 2/6/2026 10:53 AM, Danilo Krummrich wrote: >>> On Fri Feb 6, 2026 at 4:25 PM CET, Gary Guo wrote: >>>> On Fri Feb 6, 2026 at 12:41 AM GMT, Joel Fernandes wrote: >>>>> 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. 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.
