From: Wedson Almeida Filho <wedsonaf@google.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Miguel Ojeda <ojeda@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
rust-for-linux <rust-for-linux@vger.kernel.org>,
linux-kbuild <linux-kbuild@vger.kernel.org>,
Linux Doc Mailing List <linux-doc@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 00/13] [RFC] Rust support
Date: Thu, 29 Apr 2021 02:52:38 +0100 [thread overview]
Message-ID: <YIoRZizWTn7LrEuz@google.com> (raw)
In-Reply-To: <CACRpkdYM5DFLa5=t2NRnZh_TC4KXJYOuXL0oP6xcbifuNjegUg@mail.gmail.com>
On Tue, Apr 27, 2021 at 12:54:00PM +0200, Linus Walleij wrote:
> I really like the look of this. I don't fully understand it, but what
> is needed for driver developers to adopt rust is something like a
> detailed walk-through of examples like this that explains the
> syntax 100% all the way down.
Do you have a suggestion for a good place to host such walk-throughs? Also, do
you have other examples in mind that might be useful?
Have you had a chance to read the example I posted in Google's security blog?
It's not particularly complex stuff but touches on some relevant concepts:
https://security.googleblog.com/2021/04/rust-in-linux-kernel.html
> This looks good, but cannot be done like this. The assembly versions
> of writel() etc have to be used because the compiler simply will not
> emit the right type of assembly for IO access, unless the compiler
> (LLVM GCC) gains knowledge of what an IO address is, and so far
> they have not.
That code does not preclude the use of C/assembly wrappers. One way to do it
would be to define a trait that allows types to specify their read/write
functions. For example:
pub trait IoMemType {
unsafe fn write(ptr: *mut Self, value: Self);
unsafe fn read(ptr: *const Self) -> Self;
}
Then we restrict T in my original example to only allow types that implement
IoMemType. And we implement it for u8/16/32/64 as wrappers to the C/assembly
implementations.
> One *could* think about putting awareness about crazy stuff like
> that into the language but ... I think you may want to avoid it
> and just wrap the assembly. So a bit of low-level control of the
> behavior there.
Yes, I'm happy to have C/assembly be the source of truth, called from Rust
through wrappers.
> > 2. The only unsafe part that could involve the driver for this would be the
> > creation of IoMemBlock: my expectation is that this would be implemented by the
> > bus driver or some library that maps the appropriate region and caps the size.
> > That is, we can also build a safe abstraction for this.
>
> I suppose this is part of the problem in a way: a language tends to be
> imperialistic: the developers will start thinking "it would all be so much
> easier if I just rewrote also this thing in Rust".
I'm not sure I agree with this. I actually just want to hook things up to the
existing C code and expose a Rust interface that allows developers to benefit
from the guarantees it offers. Unnecessarily rewriting things would slow me
down, so my incentive is to avoid rewrites.
> > 7. We could potentially design a way to limit which offsets are available for a
> > given IoMemBlock, I just haven't thought through it yet, but it would also
> > reduce the number of mistakes a developer could make.
>
> The kernel has an abstraction for memory and register accesses,
> which is the regmap, for example MMIO regmap for simple
> memory-mapped IO:
> drivers/base/regmap/regmap-mmio.c
>
> In a way this is memory safety implemented in C.
I wasn't aware of this. I like it. Thanks for sharing.
> If Rust wants to do this I would strongly recommend it to
> try to look like regmap MMIO.
> See for example drivers/clk/sprd/common.c:
>
> static const struct regmap_config sprdclk_regmap_config = {
> .reg_bits = 32,
> .reg_stride = 4,
> .val_bits = 32,
> .max_register = 0xffff,
> .fast_io = true,
> };
> (...)
> regmap = devm_regmap_init_mmio(&pdev->dev, base,
> &sprdclk_regmap_config);
>
> It is also possible to provide a callback function to determine
> if addresses are readable/writeable.
>
> This is really a devil-in-the-details place where Rust needs
> to watch out to not reimplement regmap in a substandard
> way from what is already available.
At the moment we're only providing wrappers for things we need, so it is mostly
restricted to what I needed for Binder.
If someone wants to write a driver that would benefit from this, we will look
into it and possibly wrap the C implementation.
> Also in many cases developers do not use regmap MMIO
> because it is just too much trouble. They tend to use it
> not because "safety is nice" but because a certain register
> region is very fractured and it is easy to do mistakes and
> write into a read-only register by mistake. So they want
> this, optionally, when the situation demands it.
In Rust, we want all accesses to be safe (within reason), so we probably want to
offer something like IoMemBlock for cases when regmap-mmio is too much hassle.
> It looks nice but it is sadly unrealistic because we need to wrap
> the real assembly accessors in practice (write memory barriers
> and such) and another problem is that it shows that Rust has an
> ambition to do a parallel implementation of regmap.
There is no such ambition. The code in my previous email was written on the spot
as a demonstration per your request.
> > Would you mind sharing more about which aspect of this you feel is challenging?
>
> Good point.
>
> This explanation is going to take some space.
Thanks, I appreciate this.
> I am not able to express it in Rust at all and that is what
> is challenging about it, the examples provided for Rust
> are all about nice behaved computer programs like
> cutesey fibonnacci series and such things and not really
> complex stuff.
I'm sure you're able to express functions and arguments, for example. So going
into the details of the code would have been helpful to me.
> Your binder example is however very good, the problem
> is that it is not a textbook example so the intricacies of
> it are not explained, top down. (I'm not blaming you for
> this, I just say we need that kind of text to get to know
> Rust in the details.)
Do you think a write up about some of what's in there would be helpful? I was
planning to publish some information about the code, including performance
numbers and comparisons of past vulnerabilities once I completed the work.
Probably not to the level of detail that you're seeking but I may look into
having more details about the code if there is demand for it.
> What we need is a good resource to learn it, that
> skips the trivial aspects of the language and goes immediately
> for the interesting details.
>
> It's not like I didn't try.
> I consulted the Rust book on the website of coure.
Did you run into 'Rust for Embedded C Programmers' by any chance
(https://docs.opentitan.org/doc/ug/rust_for_c/)? It's not all up to date but I
found it useful.
> The hard thing to understand in Rust is traits. I don't understand
> traits. I have the level of "a little knowledge is dangerous" and
> I clearly understand this: all kernel developers must have
> a thorough and intuitive understanding of the inner transcendental
> meaning of the concept of a TRAIT, how it was devised, how the
> authors of the language conceptualized it, what effect it is supposed
> to have on generated assembly.
Perhaps we need a 'Rust for Linux Kernel Programmers' in a similar vain to the
page I linked above.
> The language book per se is a bit too terse.
> For example if I read
> https://doc.rust-lang.org/book/appendix-02-operators.html
>
> T: ?Sized : Allow generic type parameter to be a dynamically sized type
>
> This is just self-referential. The description is written in a
> strongly context-dependent language to make a pun ...
> I think every word in that sentence except "allow"and "to be a"
> is dependent on other Rust concepts and thus completely
> unreadable without context.
>
> Instead it is described in a later chapter:
> https://doc.rust-lang.org/book/ch19-04-advanced-types.html
>
> This is more to the point.
>
> "Rust has a particular trait called the Sized trait to
> determine whether or not a type’s size is known at compile time."
> (...) "A trait bound on ?Sized is the opposite of a trait bound on
> Sized: we would read this as “T may or may not be Sized.” This
> syntax is only available for Sized, not any other traits."
>
> But Jesus Christ. This makes me understand less not
> more.
I had similar frustrations when I started on the language, which wasn't that
long ago. One thing that I found useful was to read through some of the RFCs
related to the topic I was interested in: it was time-consuming but helped me
understand not only what was going on but the rationale as well.
> What I find very disturbing is that the authors of the Rust
> language did NOT write it. I think this may be the source
> of a serious flaw. We need this information straight from
> the horse's mouth.
Perhaps you're right... I don't share this feeling though.
> I would strongly advice the Rust community to twist the
> arms of the original Rust authors to go and review and
> edit the Rust book. Possibly rewrite parts of it. This is what
> the world needs to get a more adaptable Rust.
>
> I understand this is a thick requirement, but hey, you are
> competing with C.
I don't think of this as a competition. I'm not arguing for C to be replaced,
only for Rust to be an option for those inclined to use it.
Thanks again,
-Wedson
next prev parent reply other threads:[~2021-04-29 1:52 UTC|newest]
Thread overview: 206+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-14 18:45 [PATCH 00/13] [RFC] Rust support ojeda
2021-04-14 18:45 ` [PATCH 01/13] kallsyms: Support "big" kernel symbols (2-byte lengths) ojeda
2021-04-14 19:44 ` Matthew Wilcox
2021-04-14 19:59 ` Miguel Ojeda
2021-04-14 18:45 ` [PATCH 02/13] kallsyms: Increase maximum kernel symbol length to 512 ojeda
2021-04-14 23:48 ` Nick Desaulniers
2021-04-14 18:45 ` [PATCH 03/13] Makefile: Generate CLANG_FLAGS even in GCC builds ojeda
2021-04-14 18:59 ` Nathan Chancellor
2021-04-15 10:18 ` Miguel Ojeda
2021-04-14 23:46 ` Nick Desaulniers
2021-04-15 0:47 ` Miguel Ojeda
2021-04-14 18:45 ` [PATCH 04/13] Kbuild: Rust support ojeda
2021-04-14 23:19 ` Nick Desaulniers
2021-04-15 0:43 ` Miguel Ojeda
2021-04-15 18:03 ` Nick Desaulniers
2021-04-16 12:23 ` Miguel Ojeda
2021-04-17 19:35 ` Masahiro Yamada
2021-04-16 13:38 ` Peter Zijlstra
2021-04-16 17:05 ` Linus Torvalds
2021-04-16 17:47 ` Miguel Ojeda
2021-04-16 18:09 ` Al Viro
2021-04-16 18:57 ` Miguel Ojeda
2021-04-16 20:22 ` Willy Tarreau
2021-04-16 20:34 ` Connor Kuehl
2021-04-16 20:58 ` Willy Tarreau
2021-04-16 21:39 ` Miguel Ojeda
2021-04-16 22:04 ` Willy Tarreau
2021-04-16 22:45 ` Al Viro
2021-04-16 23:46 ` Miguel Ojeda
2021-04-17 4:24 ` Willy Tarreau
2021-04-17 15:38 ` Miguel Ojeda
2021-04-16 21:19 ` Miguel Ojeda
2021-04-16 17:34 ` Miguel Ojeda
2021-04-19 19:58 ` David Sterba
2021-04-19 20:17 ` Matthew Wilcox
2021-04-19 21:03 ` Miguel Ojeda
2021-04-19 20:54 ` Miguel Ojeda
2021-04-14 18:45 ` [PATCH 05/13] Rust: Compiler builtins crate ojeda
2021-04-14 19:19 ` Linus Torvalds
2021-04-14 19:34 ` Miguel Ojeda
2021-04-14 18:45 ` [PATCH 06/13] Rust: Module crate ojeda
2021-04-14 18:45 ` [PATCH 08/13] Rust: Export generated symbols ojeda
2021-04-14 18:46 ` [PATCH 09/13] Samples: Rust examples ojeda
2021-04-14 19:34 ` Linus Torvalds
2021-04-14 19:42 ` Miguel Ojeda
2021-04-14 19:49 ` Matthew Wilcox
2021-04-16 11:46 ` Andrej Shadura
2021-04-14 23:24 ` Nick Desaulniers
2021-04-15 7:10 ` Greg Kroah-Hartman
2021-04-15 7:39 ` Nick Desaulniers
2021-04-15 12:42 ` Miguel Ojeda
2021-04-16 13:07 ` Sven Van Asbroeck
2021-04-16 13:20 ` Greg Kroah-Hartman
2021-04-14 18:46 ` [PATCH 10/13] Documentation: Rust general information ojeda
2021-04-14 22:17 ` Nick Desaulniers
2021-04-14 23:34 ` Miguel Ojeda
2021-04-14 18:46 ` [PATCH 11/13] MAINTAINERS: Rust ojeda
2021-04-14 21:55 ` Nick Desaulniers
2021-04-14 22:02 ` Miguel Ojeda
2021-04-14 22:36 ` Nick Desaulniers
2021-04-14 18:46 ` [PATCH 12/13] Rust: add abstractions for Binder (WIP) ojeda
[not found] ` <20210414184604.23473-8-ojeda@kernel.org>
2021-04-14 19:31 ` [PATCH 07/13] Rust: Kernel crate Linus Torvalds
2021-04-14 19:50 ` Miguel Ojeda
2021-04-14 19:44 ` [PATCH 00/13] [RFC] Rust support Linus Torvalds
2021-04-14 20:20 ` Miguel Ojeda
2021-04-15 1:38 ` Kees Cook
2021-04-15 8:26 ` David Laight
2021-04-15 18:08 ` Kees Cook
2021-04-15 12:39 ` Miguel Ojeda
2021-04-14 20:09 ` Matthew Wilcox
2021-04-14 20:21 ` Linus Torvalds
2021-04-14 20:35 ` Josh Triplett
2021-04-14 22:08 ` David Laight
2021-04-14 20:29 ` Miguel Ojeda
2021-04-18 15:31 ` Wedson Almeida Filho
2021-04-15 0:22 ` Nick Desaulniers
2021-04-15 10:05 ` Miguel Ojeda
2021-04-15 18:58 ` Peter Zijlstra
2021-04-16 2:22 ` Wedson Almeida Filho
2021-04-16 4:25 ` Al Viro
2021-04-16 5:02 ` Wedson Almeida Filho
2021-04-16 5:39 ` Paul Zimmerman
2021-04-16 7:46 ` Peter Zijlstra
2021-04-16 7:09 ` Peter Zijlstra
2021-04-17 5:23 ` comex
2021-04-17 12:46 ` David Laight
2021-04-17 14:51 ` Paolo Bonzini
2021-04-19 7:32 ` Peter Zijlstra
2021-04-19 7:53 ` Paolo Bonzini
2021-04-19 8:26 ` Peter Zijlstra
2021-04-19 8:35 ` Peter Zijlstra
2021-04-19 9:02 ` Paolo Bonzini
2021-04-19 9:36 ` Peter Zijlstra
2021-04-19 9:40 ` Paolo Bonzini
2021-04-19 11:01 ` Will Deacon
2021-04-19 17:14 ` Linus Torvalds
2021-04-19 18:38 ` Paolo Bonzini
2021-04-19 18:50 ` Linus Torvalds
2021-04-22 10:03 ` Linus Walleij
2021-04-22 14:09 ` David Laight
2021-04-22 15:24 ` Wedson Almeida Filho
2021-04-26 0:18 ` Linus Walleij
2021-04-26 14:26 ` Miguel Ojeda
2021-04-26 14:40 ` Wedson Almeida Filho
2021-04-26 16:03 ` Miguel Ojeda
2021-04-27 10:54 ` Linus Walleij
2021-04-27 11:13 ` Robin Randhawa
2021-04-29 1:52 ` Wedson Almeida Filho [this message]
2021-04-26 18:01 ` Miguel Ojeda
2021-04-22 21:28 ` Miguel Ojeda
2021-04-26 0:31 ` Linus Walleij
2021-04-26 18:18 ` Miguel Ojeda
2021-04-27 11:13 ` Linus Walleij
2021-04-28 2:51 ` Kyle Strand
2021-04-28 3:10 ` Miguel Ojeda
2021-05-04 21:21 ` Linus Walleij
2021-05-04 23:30 ` Miguel Ojeda
2021-05-05 11:34 ` Linus Walleij
2021-05-05 14:17 ` Miguel Ojeda
2021-05-05 15:13 ` Enrico Weigelt, metux IT consult
2021-05-06 12:47 ` Linus Walleij
2021-05-07 18:23 ` Miguel Ojeda
2021-04-16 4:27 ` Boqun Feng
2021-04-16 6:04 ` Nick Desaulniers
2021-04-16 18:47 ` Paul E. McKenney
2021-04-19 20:35 ` Nick Desaulniers
2021-04-19 21:37 ` Paul E. McKenney
2021-04-19 22:03 ` Miguel Ojeda
2021-04-16 20:48 ` Josh Triplett
2021-04-16 8:16 ` Michal Kubecek
2021-04-16 9:29 ` Willy Tarreau
2021-04-16 11:24 ` Peter Zijlstra
2021-04-16 13:07 ` Wedson Almeida Filho
2021-04-16 14:19 ` Peter Zijlstra
2021-04-16 15:04 ` Miguel Ojeda
2021-04-16 15:43 ` Peter Zijlstra
2021-04-16 16:21 ` Miguel Ojeda
2021-04-16 15:33 ` Wedson Almeida Filho
2021-04-16 16:14 ` Willy Tarreau
2021-04-16 17:10 ` Miguel Ojeda
2021-04-16 17:18 ` Peter Zijlstra
2021-04-16 18:08 ` Matthew Wilcox
2021-04-17 11:17 ` Peter Zijlstra
2021-04-17 11:46 ` Willy Tarreau
2021-04-17 14:24 ` Peter Zijlstra
2021-04-17 14:36 ` Willy Tarreau
2021-04-17 13:46 ` David Laight
2021-04-16 17:37 ` Willy Tarreau
2021-04-16 17:46 ` Connor Kuehl
2021-04-20 0:24 ` Nick Desaulniers
2021-04-20 3:47 ` Willy Tarreau
2021-04-20 5:56 ` Greg Kroah-Hartman
2021-04-20 6:16 ` Willy Tarreau
2021-04-29 15:38 ` peter enderborg
2021-04-17 13:53 ` Wedson Almeida Filho
2021-04-17 14:21 ` Willy Tarreau
2021-04-17 15:23 ` Miguel Ojeda
2021-04-18 15:51 ` Wedson Almeida Filho
2021-04-17 12:41 ` David Laight
2021-04-17 13:01 ` Wedson Almeida Filho
2021-04-16 15:03 ` Matthew Wilcox
2021-04-17 13:29 ` Wedson Almeida Filho
2021-04-16 15:58 ` Theodore Ts'o
2021-04-16 16:21 ` Wedson Almeida Filho
2021-04-17 15:11 ` Paolo Bonzini
2021-04-16 14:21 ` Miguel Ojeda
2021-04-17 20:42 ` Richard Weinberger
2021-04-28 18:34 ` Mariusz Ceier
2021-04-28 20:25 ` Nick Desaulniers
2021-04-28 21:21 ` David Laight
2021-04-29 11:14 ` Kajetan Puchalski
2021-04-29 11:25 ` Kajetan Puchalski
2021-04-29 14:06 ` Mariusz Ceier
2021-04-29 14:13 ` Sven Van Asbroeck
2021-04-29 14:26 ` Willy Tarreau
2021-04-29 15:06 ` Al Viro
2021-04-29 16:09 ` Mariusz Ceier
2021-04-30 6:39 ` Thomas Schoebel-Theuer
2021-04-30 8:30 ` David Laight
2021-05-05 13:58 ` Enrico Weigelt, metux IT consult
2021-05-05 14:41 ` Miguel Ojeda
2022-06-20 15:11 ` Olliver Schinagl
2022-06-27 17:44 ` Miguel Ojeda
2022-07-18 6:56 ` Olliver Schinagl
2022-07-20 19:23 ` Miguel Ojeda
2022-07-20 20:21 ` Nicolas Pitre
2022-07-27 7:47 ` Olliver Schinagl
2022-07-27 13:32 ` Nicolas Pitre
2022-07-27 8:05 ` Olliver Schinagl
2022-07-28 10:21 ` Gary Guo
2022-07-28 12:09 ` Greg Kroah-Hartman
2022-07-28 12:28 ` Gary Guo
2022-07-28 20:45 ` Olliver Schinagl
2022-07-29 8:04 ` Greg Kroah-Hartman
2022-07-28 20:43 ` Olliver Schinagl
2022-10-15 14:16 ` Olliver Schinagl
2022-10-16 1:44 ` Bagas Sanjaya
2022-10-16 1:50 ` Bagas Sanjaya
2022-10-16 13:23 ` Josh Triplett
2021-04-29 5:20 Mariusz Ceier
2021-04-29 5:21 Mariusz Ceier
2021-04-29 8:18 ` David Laight
2021-05-09 21:28 Leandro Coutinho
2021-05-09 21:49 ` Greg Morenz
2021-05-09 21:55 ` Leandro Coutinho
2021-07-30 23:22 Dillan Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YIoRZizWTn7LrEuz@google.com \
--to=wedsonaf@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linus.walleij@linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=peterz@infradead.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).