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: <tbypgxb6ksoa3b5lshlczfozcpz4vvor3ypkpwocl4oczi5iyl@ufbhyyljn3zo>
Date: Tue, 16 Dec 2025 14:14:26 -0800
From: Bjorn Andersson <andersson@...nel.org>
To: Matthew Maurer <mmaurer@...gle.com>
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 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?

> 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...

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