On Wed, Apr 14, 2021 at 08:45:51PM +0200, ojeda@xxxxxxxxxx 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.
> ## Why not?
>
> Rust also has disadvantages compared to C in the context of
> the Linux kernel:
>
> - The many years of effort in tooling for C around the kernel,
> including compiler plugins, sanitizers, Coccinelle, lockdep,
> sparse... However, this will likely improve if Rust usage in
> the kernel grows over time.
This; can we mercilessly break the .rs bits when refactoring? What
happens the moment we cannot boot x86_64 without Rust crap on?
We can ignore this as a future problem, but I think it's only fair to
discuss now. I really don't care for that future, and IMO adding this
Rust or any other second language is a fail.
> Thirdly, in Rust code bases, most documentation is written alongside
> the source code, in Markdown. We follow this convention, thus while
> we have a few general documents in `Documentation/rust/`, most of
> the actual documentation is in the source code itself.
>
> In order to read this documentation easily, Rust provides a tool
> to generate HTML documentation, just like Sphinx/kernel-doc, but
> suited to Rust code bases and the language concepts.
HTML is not a valid documentation format. Heck, markdown itself is
barely readable.
> Moreover, as explained above, we are taking the chance to enforce
> some documentation guidelines. We are also enforcing automatic code
> formatting, a set of Clippy lints, etc. We decided to go with Rust's
> idiomatic style, i.e. keeping `rustfmt` defaults. For instance, this
> means 4 spaces are used for indentation, rather than a tab. We are
> happy to change that if needed -- we think what is important is
> keeping the formatting automated.
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.
> Another important topic we would like feedback on is the Rust
> "native" documentation that is written alongside the code, as
> explained above. We have uploaded it here:
>
> https://rust-for-linux.github.io/docs/kernel/
>
> We like how this kind of generated documentation looks. Please take
> a look and let us know what you think!
I cannot view with less or vim. Therefore it looks not at all.
> - Boqun Feng is working hard on the different options for
> threading abstractions and has reviewed most of the `sync` PRs.
Boqun, I know you're familiar with LKMM, can you please talk about how
Rust does things and how it interacts?
