linux-kernel - Re: [PATCH RFC] soc: qcom: socinfo: Re-implement in 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGSQo00DqmA1ihePtOWqv37h3U0NjN3ka853XA7w+6aCUkxS5g@mail.gmail.com>
Date: Tue, 16 Dec 2025 14:32:38 -0800
From: Matthew Maurer <mmaurer@...gle.com>
To: Bjorn Andersson <andersson@...nel.org>
Cc: Greg KH <gregkh@...uxfoundation.org>, Konrad Dybcio <konradybcio@...nel.org>, 
	Satya Durga Srinivasu Prabhala <satyap@...cinc.com>, 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>, Trilok Soni <tsoni@...cinc.com>, linux-kernel@...r.kernel.org, 
	linux-arm-msm@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH RFC] soc: qcom: socinfo: Re-implement in Rust

On Tue, Dec 16, 2025 at 2:06 PM Bjorn Andersson <andersson@...nel.org> wrote:
>
> On Tue, Dec 16, 2025 at 12:55:11PM -0800, Matthew Maurer wrote:
> > On Tue, Dec 16, 2025 at 12:52 PM Bjorn Andersson <andersson@...nel.org> wrote:
> > >
> > > On Sat, Dec 13, 2025 at 08:24:55AM -0800, Matthew Maurer wrote:
> > > > On Sat, Dec 13, 2025 at 5:57 AM Greg KH <gregkh@...uxfoundation.org> wrote:
> > > > >
> > > > > Shouldn't this all just be in 1 .rs file?  By not doing that, you have a
> > > > > number of public symbols (that are very generic), that will "pollute"
> > > > > the global namespace of the kernel symbol table (unless rust does this
> > > > > somehow differently?)
> > > >
> > > > Rust produces one compilation unit per "crate". In this case,
> > > > `socinfo` is the crate, and the other files are included as "modules".
> > > > Symbols defined in them are not public unless annotated with `pub`.
> > > > `pub(crate)` makes them only exported within the scope of the crate,
> > > > i.e. inside the single produced `.o` file.
> > > >
> > >
> > > Does this imply that a fully converted drivers/soc/qcom would have ~50
> > > subdirectories in it then?
> >
> > Not necessarily. Directories are not mandatory for a Rust module,
> > whether to do things this way is a code structure/stylistic decision.
> > I did it in this case primarily because I wanted to separate out the
> > large in-code data table (e.g. SOC_IDS) and the logic for speaking to
> > the smem driver from the rest of the code.
>
> Separating out the logic for interfacing the smem driver sounds like a
> quite reasonable proposition, to the point that I'd expect this to be a
> module of its own?

Currently the socinfo driver is the only user of that code, so
splitting it into a full kernel module would just add overhead to no
benefit. If we had multiple Rust drivers, we could consider between
either referencing the same file multiple places (would cause minor
code bloat, but avoid module overhead) or making it a module.

>
> > If you have a preference
> > for a single file, I can very easily put it all in a single file.
>
> My preference is that this follows whatever is the idiomatic model for
> in-kernel Rust. Whichever way that pulls us would be the answer to my
> question above...

drivers/gpu/{drm/nova,nova-core} use multi-file layout (with a single
kernel module, and multiple Rust files), so I would say that it is
idiomatic to use multiple files to define a single kernel module.

As far as a directory per kernel module, it generally appears that
multi-file Rust modules happen to have an exclusive directory with the
exception of the binder driver. However, that may be coincidence, as
most of those are defining a single high level kernel module, not a
cluster of related kernel modules.

Danilo or Miguel might have an opinion here on when directories should
be used? The Rust Coding Guidelines [1] don't seem to have any
opinions on directory structure, and I was unable to find any generic
guidance for general kernel development.

Were it my project, I would use directories for any Rust module that
was multi-file, and just use a regular file for Rust modules which
don't have a natural division into multiple pieces.

[1]: https://docs.kernel.org/rust/coding-guidelines.html

>
> Regards,
> Bjorn
>
> >
> > >
> > > Regards,
> > > Bjorn
> > >
> > > > > But putting this all in 1 file should solve all of that, and remove all
> > > > > global symbols.  Especially for just a small and simple driver like
> > > > > this, no need to split it up at all.
> > > >
> > > > I'm willing to put it all in one file if that's preferred for
> > > > organizational purposes, but as explained above, this shouldn't bloat
> > > > the symbol count in Rust. If it were my own codebase this would be
> > > > separate files, so up to y'all what level of granularity you'd prefer.
> > > >
> > > > >
> > > > > thanks,
> > > > >
> > > > > greg k-h