Re: [PATCH RFC] soc: qcom: socinfo: Re-implement in Rust

[Bjorn Andersson]

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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> 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