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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGSQo02mx361GmTzCCiMyQZUfnsWCRTbvFpBX73W=PZnhJ0wcA@mail.gmail.com>
Date: Tue, 16 Dec 2025 12:55:11 -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 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. If you have a preference
for a single file, I can very easily put it all in a single file.

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