[lkml]   [2021]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 00/13] [RFC] Rust support
    On Wed, Apr 14, 2021 at 08:45:51PM +0200, 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) {


    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:
    > 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?

     \ /
      Last update: 2021-04-15 21:01    [W:13.462 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site