Re: [TECH TOPIC] Rust for Linux

[Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>]

On Wed, Jul 7, 2021 at 6:55 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> No, I meant just which targets are enabled at all, regardless of whether
> we are cross-building.
>
> https://doc.rust-lang.org/nightly/rustc/platform-support.html lists only
> arm64, arm32, hexagon, mips, powerpc, riscv, sparc64, s390x,
> x86-32 and x86-64, in a number of variations (plus a few others
> that don't run Linux). I assume these all have user space support,
> while the other architectures that have llvm support (arc, csky, m68k,
> sparc32) would work in principle for building the kernel but are lacking
> a standard library port.

Ah, I see what you mean. Yes, you are right, building "for user
space", i.e. including building `std` etc. is more work (because `std`
includes things that rely on an operating system being present; e.g.
printing, sockets, etc.), while supporting `core` and `alloc` is
easier (and it is the only thing we need for the kernel).

> Ah, so I assume this is not going to be the version from my distro then.

Yeah, in the beginning, I don't think they will always match. A couple
ways around that:

  - Distros could distribute the Rust toolchain they used to build the
kernel as a separate package; for the kernel only. This is what I
would recommend.

  - Distros could simply make the kernel compile with a different
version even if it is not supported by us -- i.e. it is possible, it
is just that we cannot guarantee it can be done *if* an unstable
feature happens to change between versions. This has a higher
probability of happening until we drop `alloc` from the kernel tree,
because `alloc` is part of the standard library and currently uses
some compiler magic.

Later on, when we manage to compile the kernel without unstable
features, then we only need to state a minimum version, like for
GCC/Clang.

> Well, this was my question: if the libgccjit interface is stable enough,
> it should be possible to port the patches to every version we still
> support in the kernel. gcc-4.9.4 does not have libgccjit, but the later
> ones do.
>
> The patches are only for an unreleased gcc-12 tree but they
> don't look too invasive, so maybe they could eventually get
> backported to stable compilers (not upstreamed, but at least
> used for my builds).
>
> I don't really care about the outdated fix releases (9.3, 8.4,
> 7.3, ...) but I try to make sure the latest build of each major
> gcc version works.

I see -- let's contact offline the author about this. I will Cc you
(or if you write the email, please Cc me).

> According to
> https://gcc.gnu.org/onlinedocs/jit/topics/compatibility.html
> the ABI should be stable across all gcc versions, so if we
> can get it to work with an old gcc release it would work with
> all newer ones as well, but obviously anything built against the
> patched library won't work against a newer version of the library
> if that doesn't also have those patches.
>
> My guess is that the ABI is also stable across target architectures,
> but I could not confirm that. If this is true, then building against
> the oldest supported libgccjit would make it work with any later
> (patched) libgccjit, but we'd need to pass the correct libgccjit.so
> file that matches the gcc version used for building the kernel
> and the target architecture.

Agreed, we could try that.

> This would clearly only work for gcc-12 or later, otherwise it
> does seem plausible. As far as I can tell, the patches just add features
> that may be generally useful, not just for rust.

What I meant is trying to convince GCC to have the patches in the
older releases -- but yeah, it is unlikely (they only accept bugfixes,
right?).

Cheers,
Miguel