[HN Gopher] A GPIO Driver in Rust
___________________________________________________________________
A GPIO Driver in Rust
Author : brundolf
Score : 54 points
Date : 2021-07-19 19:34 UTC (3 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| axegon_ wrote:
| I'm already in bed so reading the code on my phone is really
| painful. That said, at first glance this looks really promising.
| This is great news on two fronts: on one hand this will
| drastically simplify supporting devices and would speed up
| development a lot. Also it's great news for rust: the fact that
| it's been used in a place where it can show it's potential and
| isn't another case of "let's use rust for the sake of using
| rust", which is a lot more common than I used to imagine.
| gnull wrote:
| > the fact that it's been used in a place where it can show
| it's potential
|
| And more importantly, a place where C++ has failed.
| brundolf wrote:
| Do you have specific knowledge of how C++ tried and failed to
| apply to this usecase?
| gnull wrote:
| Even though neither Rust nor C++ are supported Kernel
| languages, Rust has passed a few iterations of trial and
| discussion, C++ on the other hand was filtered out at the
| first one. Linus refused to even take C++ seriously (and
| also mentioned trying it for Kernel in 1992) [1].
|
| Some might argue this doesn't qualify as "C++ trying", but
| I think it does.
|
| [1]: http://harmful.cat-v.org/software/c++/linus
| Animats wrote:
| And in the end, it's basically safe PEEK and POKE.
| wahern wrote:
| The unsafe readb and writeb is hidden inside another API--IoMem
| module. The same API could be created for C, but isn't--either
| deliberately or just because nobody bothered.
| uncomputation wrote:
| This is a perfect resource for exactly the use case Rust is
| (supposedly?) designed for. It's a great, brief way to really get
| the gist of the language.
| bsder wrote:
| This ... isn't really a great example--either of Rust or of
| embedded programming in Rust.
|
| Someone should ask one of the Rust Embedded folks to review this
| and provide commentary.
| stefan_ wrote:
| All the Rust Embedded code I've seen is off the rails deep into
| "C++ template meta programming" and the absolute antithesis of
| what to do.
|
| Even the code here, given the absolute impossibility to detect
| errors with something like a GPIO chip, has too many Results.
| It's an incredible code smell for "terrible abstractions".
| jabedude wrote:
| > This ... isn't really a great example--either of Rust or of
| embedded programming in Rust.
|
| Why not? You could also feel free to respond to the mailing
| list with your critiques
| saghm wrote:
| In the Rust code, where is the Result type they're using defined?
| I assume that the parameterless `Result` return types are
| intended to be `Result<()>`, and I suppose it might be possible
| to achieve this with default generics, but I've never seen that
| used before, so it sticks out as a bit odd to me.
| nicoburns wrote:
| I see they're importing `kernel::prelude::*`, so I would guess
| there.
| swsieber wrote:
| It looks like something like that is indeed possible. See a
| post on the rust internals forum where that's setup with a type
| alias. It was called `Fallible` in that post, but it's common
| in the Rust ecosystem to override the default Result type with
| a custom error parameter but still calling it Result.
|
| https://internals.rust-lang.org/t/make-stds-result-a-type-al...
|
| So I'd guess in this driver that the Result type being used is
| a type alias defined in the prelude that's glob imported.
| dexwiz wrote:
| Look's like kernel::Result does just that. It is re-exported as
| part of the prelude.
|
| https://rust-for-linux.github.io/docs/kernel/type.Result.htm...
| secondcoming wrote:
| In the function 'pl061_irq_type' the original code has (line
| 224): writeb(gpiois, pl061->base + GPIOIS);
| writeb(gpioibe, pl061->base + GPIOIBE); writeb(gpioiev,
| pl061->base + GPIOIEV);
|
| but the translated code has a differing order:
| pl061.base.writeb(gpioiev, GPIOIEV);
| pl061.base.writeb(gpiois, GPIOIS);
| pl061.base.writeb(gpioibe, GPIOIBE);
|
| Isn't the order of operations important when talking to I/O?
| uxp100 wrote:
| I doubt order of operations is important here, but nice catch,
| I bet that was not on purpose.
| geocar wrote:
| > Isn't the order of operations important when talking to I/O?
|
| Sometimes, yes. It's hard to tell if this is one of those times
| without a closer look at the documentation or at least some
| experimentation, but because "Rust is Memory Safe(tm)" I think
| it is safe assume this is fine simply because it compiled, and
| without knowing anything about you, would recommend you assume
| the same, because, well, Rust. Obviously.
___________________________________________________________________
(page generated 2021-07-19 23:00 UTC)