On Wed Feb 11, 2026 at 10:09 PM CET, Joel Fernandes wrote: > On Tue, Feb 10, 2026 at 11:07:37AM +0100, Danilo Krummrich wrote: >> On Mon Feb 9, 2026 at 10:42 PM CET, Joel Fernandes wrote: >> > rust/kernel/clist.rs | 320 +++++++++++++++++++++++++++++++++++++++++ >> >> I think we should move this under rust/kernel/ffi/ to make it obvious that >> this >> is FFI infrastructure. >> >> > diff --git a/rust/kernel/clist.rs b/rust/kernel/clist.rs >> > new file mode 100644 >> > index 000000000000..8aa72b5d54be >> > --- /dev/null >> > +++ b/rust/kernel/clist.rs >> > @@ -0,0 +1,320 @@ >> > +// SPDX-License-Identifier: GPL-2.0 >> > + >> > +//! A C doubly circular intrusive linked list interface for rust code. >> >> Here and in the struct documentation, I'd suggest to clearly point out the >> use-cases, i.e. that this infrastructure is for FFI use-cases only and should >> not be used otherwise in drivers, etc > > I am curious why we would not want to have drivers be able to use CList. I > thought that was the point of making it pub at the module/item level as well. > I think it is possible a rust driver may have a reference to a CList in the > future.
It is a (partially) unsafe API built to support FFI interactions. The absolute majority of drivers should not have any FFI interactions themselves. nova-core is the "odd one" as it will have an interface with a C driver (vGPU). Besides a few "odd" drivers, there may be quite some subsystem abstractions that become users of the API. In the future build system, subsystems and drivers will become individual crates. > But I will update the current usecase above, as you suggested, good point.
