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

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Z6pDEyDcmhxqE0U4@pollux>
Date: Mon, 10 Feb 2025 19:18:59 +0100
From: Danilo Krummrich <dakr@...nel.org>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, Lyude Paul <lyude@...hat.com>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Alexander Lobakin <aleksander.lobakin@...el.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	Liam Girdwood <lgirdwood@...il.com>, Lukas Wunner <lukas@...ner.de>,
	Mark Brown <broonie@...nel.org>,
	Maíra Canal <mairacanal@...eup.net>,
	Robin Murphy <robin.murphy@....com>,
	Simona Vetter <simona.vetter@...ll.ch>,
	Zijun Hu <quic_zijuhu@...cinc.com>, linux-usb@...r.kernel.org,
	rust-for-linux@...r.kernel.org,
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Subject: Re: [PATCH v4 2/9] rust/kernel: Add faux device bindings

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