Re: [TECH TOPIC] Rust for Linux

Linus Walleij
2021-07-19T13:53:44Z

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