From: Peter Zijlstra <peterz@infradead.org> To: Wedson Almeida Filho <wedsonaf@google.com> Cc: ojeda@kernel.org, Linus Torvalds <torvalds@linux-foundation.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, rust-for-linux@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/13] [RFC] Rust support Date: Fri, 16 Apr 2021 09:09:01 +0200 [thread overview] Message-ID: <YHk4DZE1ZWTiBB1f@hirez.programming.kicks-ass.net> (raw) In-Reply-To: <YHj02M3jMSweoP4l@google.com> On Fri, Apr 16, 2021 at 03:22:16AM +0100, Wedson Almeida Filho wrote: > On Thu, Apr 15, 2021 at 08:58:16PM +0200, Peter Zijlstra wrote: > > On Wed, Apr 14, 2021 at 08:45:51PM +0200, ojeda@kernel.org wrote: > > > > > Rust is a systems programming language that brings several key > > > advantages over C in the context of the Linux kernel: > > > > > > - No undefined behavior in the safe subset (when unsafe code is > > > sound), including memory safety and the absence of data races. > > > > And yet I see not a single mention of the Rust Memory Model and how it > > aligns (or not) with the LKMM. The C11 memory model for example is a > > really poor fit for LKMM. > > We don't intend to directly expose C data structures to Rust code (outside the > kernel crate). Instead, we intend to provide wrappers that expose safe > interfaces even though the implementation may use unsafe blocks. So we expect > the vast majority of Rust code to just care about the Rust memory model. > > We admittedly don't have a huge number of wrappers yet, but we do have enough to > implement most of Binder and so far it's been ok. We do intend to eventually > cover other classes of drivers that may unveil unforeseen difficulties, we'll > see. > > If you have concerns that we might have overlooked, we'd be happy to hear about > them from you (or anyone else). Well, the obvious example would be seqlocks. C11 can't do them. The not sharing of data structures would avoid most of that, but will also cost you in performance. Simlar thing for RCU; C11 can't optimally do that; it needs to make rcu_dereference() a load-acquire [something ARM64 has already done in C because the compiler might be too clever by half when doing LTO :-(]. But it's the compiler needing the acquire semantics, not the computer, which is just bloody wrong. And there's more sharp corners to be had. But yes, if you're not actually sharing anything; and taking the performance hit that comes with that, you might get away with it. > > HTML is not a valid documentation format. Heck, markdown itself is > > barely readable. > > Are you stating [what you perceive as] a fact or just venting? If the former, > would you mind enlightening us with some evidence? I've yet to see a program that renders HTML (including all the cruft often used in docs, which might include SVG graphics and whatnot) sanely in ASCII. Lynx does not qualify, it's output is atrocious crap. Yes, lynx lets you read HTML in ASCII, but at the cost of bleeding eyeballs and missing content. Nothing beats a sane ASCII document with possibly, where really needed some ASCII art. Sadly the whole kernel documentation project is moving away from that as well, which just means I'm back to working on an undocumented codebase. This rst crap they adopted is unreadable garbage. > > It is really *really* hard to read. It has all sorts of weird things, > > like operators at the beginning after a line break: > > > > if (foo > > || bar) > > > > which is just wrong. And it suffers from CamelCase, which is just about > > the worst thing ever. Not even the C++ std libs have that (or had, back > > when I still did knew C++). > > > > I also see: > > > > if (foo) { > > ... > > } > > > > and > > > > if foo { > > } > > > > the latter, ofcourse, being complete rubbish. > > There are advantages to adopting the preferred style of a language (when one > exists). We, of course, are not required to adopt it but I am of the opinion > that we should have good reasons to diverge if that's our choice in the end. > > "Not having parentheses around the if-clause expression is complete rubbish" > doesn't sound like a good reason to me. Of course it does; my internal lexer keeps screaming syntax error at me; how am I going to understand code when I can't sanely read it? The more you make it look like (Kernel) C, the easier it is for us C people to actually read. My eyes have been reading C for almost 30 years by now, they have a lexer built in the optical nerve; reading something that looks vaguely like C but is definitely not C is an utterly painful experience. You're asking to join us, not the other way around. I'm fine in a world without Rust.
next prev parent reply other threads:[~2021-04-16 7:09 UTC|newest] Thread overview: 201+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-14 18:45 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 07/13] Rust: Kernel crate ojeda 2021-04-14 19:31 ` Linus Torvalds 2021-04-14 19:50 ` Miguel 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 2021-04-14 18:46 ` [PATCH 13/13] Android: Binder IPC in Rust (WIP) 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 [this message] 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 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 2021-04-29 5:20 Mariusz Ceier 2021-04-29 5:21 Mariusz Ceier 2021-04-29 8:18 ` David Laight 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=YHk4DZE1ZWTiBB1f@hirez.programming.kicks-ass.net \ --to=peterz@infradead.org \ --cc=gregkh@linuxfoundation.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kbuild@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=ojeda@kernel.org \ --cc=rust-for-linux@vger.kernel.org \ --cc=torvalds@linux-foundation.org \ --cc=wedsonaf@google.com \ --subject='Re: [PATCH 00/13] [RFC] Rust support' \ /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
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).