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