Re: [TECH TOPIC] Rust for Linux

[Linus Walleij <linus.walleij@linaro.org>]

On Mon, Jul 19, 2021 at 2:24 PM Wedson Almeida Filho
<wedsonaf@google.com> wrote:

> 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

My first impression is that this looks very good compared to other Rust
code I have seen, and it looks very intuitive and maintainable.

use kernel::{
    amba, bit, declare_id_table, device, gpio,
    io_mem::IoMem,
    irq::{self, IrqData, LockedIrqData},
    power,
    prelude::*,
    sync::{IrqDisableSpinLock, Ref},
};

I think people want to see the code inside these classes as well,
can we browse it? Especially the gpio class in my case,
because i want to know what happens when you do
impl gpio::Chip for PL061Device { ... } I suppose it is just
a C wrapper to the struct gpio_chip?

I've got questions but they are mostly due to my lack of understanding
of Rust idioms I think. For example:

    fn unmask(data: &Ref<DeviceData>, irq_data: &IrqData) {
        let mask = bit(irq_data.hwirq() % u64::from(PL061_GPIO_NR));
        let _guard = data.lock();
        if let Some(pl061) = data.resources() {
            let gpioie = pl061.base.readb(GPIOIE) | mask;
            let _ = pl061.base.try_writeb(gpioie, GPIOIE);
        }
    }

I suppose _guard will be unlocked automatically when we leave
the function? It's a bit like with Make, it is necessary to know
what is implicit.

Then the "_" variable is some kind of idiom for a throw-away
variable I guess. Can it be named "foo" or is the "_" just specially
magic?

It looks like stuff we can even maintain superficially without
being super versed in Rust. Simple things can be altered
without knowing exactly how the language works.

> (I tested iton QEMU through the sysfs interface and also gpio-keys as QEMU
> uses one of the PL061 pins as the power button.)

Fair enough.

> 1. State created on `probe` is ref-counted.
> 2. Hardware resources (device mem and irq in this case) are "revocable".
> 3. On `remove`, we automatically revoke access to hardware resources, then free
> them.

This is neat. Just generally speaking I like the looks of this
from a driver subsystem point of view. Unless the code in the
Kernel::classes is horrible that is.

Yours,
Linus Walleij