Re: [PATCH v4 2/9] rust/kernel: Add faux device bindings

[Danilo Krummrich <dakr@kernel.org>]

On Mon, Feb 10, 2025 at 04:32:15PM +0000, Benno Lossin wrote:
> On 10.02.25 13:30, Greg Kroah-Hartman wrote:
> > From: Lyude Paul <lyude@redhat.com>
> > 
> > This introduces a module for working with faux devices in rust, along with
> > adding sample code to show how the API is used. Unlike other types of
> > devices, we don't provide any hooks for device probe/removal - since these
> > are optional for the faux API and are unnecessary in rust.
> 
> For me it would be useful to know why this is the case. I looked at the
> dummy regulator driver and it still has a `probe` function. Presumably,
> because it has to wait until other resources are usable and that is the
> case once `probe` gets called. But doesn't the same hold for Rust? Or
> are Rust modules loaded later than C modules? Because if I were to
> rewrite the regulator driver in Rust (assuming we had the abstractions),
> the `probe` code would be put into the `Module::init` function, right?
> Or am I missing something?

AFAICS, the only reason for the dummy regulator driver to have probe() is
because it calls devm_regulator_register() (which given that it neither ever
removes the driver nor the device is meaningless, but let's ignore that).

Actually, not even that would be a blocker, since the same would be valid as
long as you ensure to call devm_*() after faux_device_create() and before
faux_device_remove(). But obviously, it's way cleaner to enforce this through
having the scope of the probe() callback.

In Rust we only need devres for real device resources, which a faux device can
never have. Given the example above, in Rust we wouldn't have anything like
devm_regulator_register(), but a module structure with a regulator::Registration
member, such that the registration is automatically removed when the module is
dropped.

I cannot predict if we ever gonna need probe() for the faux bus in Rust. Maybe
at some point we will, and then we can add the corresponding abstraction. But
for now, I don't see what we would need it for.