Re: [TECH TOPIC] Rust for Linux

Wedson Almeida Filho
2021-07-19T17:32:12Z

On Mon, Jul 19, 2021 at 04:02:38PM +0200, Arnd Bergmann wrote:
> On Mon, Jul 19, 2021 at 3:15 PM Wedson Almeida Filho
> <wedsonaf@google.com> wrote:
> > On Mon, Jul 19, 2021 at 01:24:49PM +0100, Wedson Almeida Filho wrote:
> > > On Fri, Jul 09, 2021 at 12:13:25AM +0200, Linus Walleij wrote:
> > > > I have seen that QEMU has a piece of code for the Arm PrimeCell
> > > > PL061 GPIO block which corresponds to drivers/gpio/gpio-pl061.c
> > > > Note that this hardware apart from being used in all Arm reference
> > > > designs is used on ARMv4T systems that are not supported by
> > > > LLVM but only GCC, which might complicate things.
> > >
> > > Here is a working PL061 driver in Rust (converted form the C one):
> > > https://raw.githubusercontent.com/wedsonaf/linux/pl061/drivers/gpio/gpio_pl061_rust.rs
> >
> > I'm also attaching an html rending of the C and Rust versions side by side where
> > I try to line the definitions up to make it easier to contrast the two
> > implementations.
>
> Thanks a lot, this looks extremely helpful!

Thanks for taking the time to check it out.

> I have a couple of questions to understand some of the differences to the
> C version, and what the reasons are for those:
>
> - All the dev_dbg() seem to be replaced with pr_debug!(). Does that mean
> we lose the information about the device instance in the output, or is
> that magically added back?

At the moment we lose information about the device, but simply because we
haven't implemented dev_ variants yet, there is no fundamental reason for this
though.

> - There is a lock of type IrqDisableSpinLock, which sounds like it would
> correspond to a spinlock_t that is always locked with spin_lock_irqsave(),
> but the original driver uses raw_spin_lock_irqsave(). Does that mean it
> won't work on CONFIG_PREEMPT_RT until both types are supported?

Yes, it uses spinlock_t. But again, just because we don't have an implementation
that uses raw_spinlock_t yet.

> - What's with all the CamelCase? Is that enforced by the language, or
> can we use the same identifiers here that we have in the C version?

I see the Miguel and Linus have already chimed in :)

> - What is the mechanism behind power::Operations that replaces the
> #ifdef CONFIG_PM of the C version? Will the rust compiler just drop
> the dead code when CONFIG_PM is disabled?

It's not there yet, but the idea is to wrap the place where `drv.pm` is
initialised in the amba code with `if cfg!(CONFIG_PM)` -- if CONFIG_PM is
disabled, all references to PM code are gone and they are removed by the
compiler. This way we move configuration-dependent code out of drivers and into
core libraries.

Cheers,
-Wedson