Re: linux-next: manual merge of the rust tree with Linus' tree

From: Miguel Ojeda
Date: Fri Jul 15 2022 - 07:01:22 EST

On Fri, Jul 15, 2022 at 11:02 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> Ok; I'm supposing that'll be sorted by the time rust happens.

No, it most likely won't, and I don't see why you would assume that,
or why we would want to block Rust support on that.

> There's quite a few things affecting code-gen; rustc not using the exact
> same compiler arguments is going to create a head-ache.

Yes, a GCC-like driver in `rustc` would be nice for projects like the
kernel. The GCC Rust project will support GCC-like flags, as far as I

(Cc'ing Antoni, Arthur, Josh, Philip).

> But does it support everything clang does now? If not, you need to
> express that in Kconfig and disable the features it doesn't carry. So
> even for a single rustc version will you need RUSTC_HAS_ stuff.

You could still make everything work around the `RUST` symbol, no need
to "litter everything" (as you said) just yet. :)

> What about CC_HAS_IBT? Can rust generate sane IBT code? Current next
> doesn't seem to have anything there, suggesting I can't build an IBT
> enabled kernel if rust is on (or rather, it'll build, but it'll also
> burn at boot).
> What if LLVM were to grow -mindirect-branch-cs-prefix (please!) and rust
> doesn't have it? Same if LLVM finally stops generating those pesky
> conditional tail-calls, will rust continue emitting them?
> I'm thinking of the kCFI work, will rustc support that from day 1 or
> will that only work when not building any rust.
> There being a single rustc is not a single target, every compiler
> version grows (and breaks) new features. And for some reason we seem to
> change the actual kernel calling convetion a lot of late :/
> Currently we can support a feature when one compiler version supports it
> (either gcc or clang), but the moment rust becomes a mandatory part of
> the kernel build (and I dread that day) we'll need to
> wait/update/wrangle at least two different toolchains to implement the
> feature in a consistent manner before we can use it.
> I also don't see any RUST -mfentry support...

I think you are getting way too ahead.

Merging the Rust support now is meant to evaluate whether Rust _as a
language_ makes sense for the kernel, whether we can write enough % of
kernel code in the safe subset (and whether that brings enough
advantages), etc.

It is not meant to provide "day 1 support" for everything. In fact,
getting merged now is what will allow to grow support for everything
needed everywhere: not just in terms of compiler flags, faster
integration of LLVM codegen/mitigation features in `rustc`, new
frontends and backends (`rustc_codegen_gcc` and GCC Rust), etc.; but
also within the kernel, in terms of safe abstractions for kernel APIs,
kernel maintainers' experience with Rust, etc.