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

["Danilo Krummrich" <dakr@kernel.org>]

On Wed Dec 17, 2025 at 12:13 AM CET, Bjorn Andersson wrote:
> On Tue, Dec 16, 2025 at 02:13:08PM -0800, Matthew Maurer wrote:
>> Rust likely does not provide any significant benefits for the socinfo
>> driver itself, aside from having caught the slight disconnect
>> (mentioned on the other thread) where it should probably be an
>> auxiliary device because it assumes that the `qcom-smem` device will
>> remain active as long as it does.

I want to highlight that this is an existing issue in the C driver that has been
caught in Rust by the language itself.

However, a Rust implementation of this driver ensures correctness for much more
potential pitfalls. For instance, the C debugfs infrastructure requires the user
to ensure that the exported data remains alive for the duration it is exposed
via debugfs. In Rust, it is not possible to violate this lifetime relationship
without producing a compile time error.

This is just one example, and I assume there are many more (I haven't read the
full patch). Maybe Matthew can chime in again and give some more examples.

Again I haven't read the full patch in detail, but it is obvious that is a
fairly trivial driver. Yet I think there is room bugs / mistakes that can be
caught by a Rust implementation.

>> 
>
> Yes, this isn't unique to Rust.

The auxiliary bus and the corresponding lifetime guarantees are not unique to
Rust. However, with Rust's type system and the corresponding implementation of
the driver model in Rust we can ensure (at compile time) that driver
implementations remain within the given boundaries of those lifetime guarantees.

This is a siginificant advantage -- violations of drivers using device resources
after device / driver unbind is a very common source of mistakes. Most of them
we can catch at compile time in Rust drivers.

- Danilo