Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210414184604.23473-1-ojeda@kernel.org> <20210414184604.23473-11-ojeda@kernel.org>
 <CAKwvOdmXNAm+TcypR0dCayp9bJ7RFcgLx5sB8_2MfzO31T3PJg@mail.gmail.com>
In-Reply-To: <CAKwvOdmXNAm+TcypR0dCayp9bJ7RFcgLx5sB8_2MfzO31T3PJg@mail.gmail.com>
From:   Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Thu, 15 Apr 2021 01:34:25 +0200
Message-ID: <CANiq72nnKU=TUxb0NGqwO_V-TJP9DOkzoYteVi2uhBgv3UB8cw@mail.gmail.com>
Subject: Re: [PATCH 10/13] Documentation: Rust general information
To:     Nick Desaulniers <ndesaulniers@google.com>
Cc:     Miguel Ojeda <ojeda@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        rust-for-linux@vger.kernel.org,
        Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
        Linux Doc Mailing List <linux-doc@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Alex Gaynor <alex.gaynor@gmail.com>,
        Geoffrey Thomas <geofft@ldpreload.com>,
        Finn Behrens <me@kloenk.de>,
        Adam Bratschi-Kaye <ark.email@gmail.com>,
        Wedson Almeida Filho <wedsonaf@google.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Nick,

Thanks a lot for looking into this!

On Thu, Apr 15, 2021 at 12:18 AM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> Was this TODO meant to be removed, or is it still pending? If pending,
> on what? Being able to link back on itself if/once merged?

Still pending -- the plan is to upload the docs to kernel.org rather
than have them on GitHub, and ideally have one version done from the
CI automatically on e.g. every merge, but that requires some sorting
out.

But yeah, I could have put here the link to the temporary docs in
GitHub for the moment, good catch! +1

> Consider if the docs need any change here based on behavior related to
> Panics based on feedback thus far in the thread.

Indeed, it should be a very rare occurrence. I will add a sentence
saying that one needs to be really sure there is no other way out than
panicking.

I have to write a few more bits regarding some new guidelines we follow/enforce.

> That link has a comment that this was fixed.  Is the comment now stale?

There were a couple things to resolve regarding LLVM 12 last time I
looked into it, so I didn't update it (also, it is safer in general to
use the recommended nightly -- one never knows when things may break,
plus some nightlies do not include all the tools like `rustfmt`).

So my current plan is to recommend a given nightly, and update it only
when needed, in tandem with the CI builds (we also test
different/newer nightlies in the CI when possible, e.g. when the LLVM
12 bits are resolved, then we will also test one with LLVM 12).

> Perhaps worth another cross reference to :ref:`kbuild_llvm`?
> https://www.kernel.org/doc/html/latest/kbuild/llvm.html#getting-llvm
> Perhaps amend that then link to it from here?

+1

> Avoid terms like recent and modern.  Otherwise in a few years 0.56.0
> will be archaic, not recent, and you'll need to update your docs.  So

+1

> bindgen does not distribute libclang?

AFAIK, no, `bindgen` expects you to provide/install `libclang` (and
you have some knobs to control how it searches for it). But it looks
like they also allow to link it statically.

I was looking into this a while ago to upload a static version to
kernel.org somewhere (actually, a full Clang/LLVM and the rest of
tools for Rust support), so that kernel developers had an easier time
setting things up. Konstantin Ryabitsev told me it would be possible,
but we need to sort out a few details.

> Please reorder; prefer LLVM=1 to CC=clang.  Probably worth another
> cross reference to :ref:`kbuild_llvm`.

Will do!

> "new" as in changed, or "new" as in Rust previously did not mangle symbols?

Changed -- currently (in stable) they use what they call the `legacy`
mangling scheme, which is very similar to C++'s (and used the same
prefix, `_Z`).

Cheers,
Miguel