Re: [TECH TOPIC] Rust for Linux

Arnd Bergmann
2021-07-19T14:02:58Z

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!

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?

- 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?

- 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?

- 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?

Arnd