rust-for-linux / linux Goto Github PK

We couldn't do it right away in #52 because rustc required a fix (rust-lang/rust#81117, rust-lang/rust#81118).

The fix is now in (rust-lang/rust@f9275e1) and available since the 2021-01-21 nightly, so now we can go ahead and make the change.

Hi,

This is a catogorie wish issue. The goal is to have an in rust written kernel module that doesn't need (special) hardware
in the mainline kernel. Have a rust kernel module that works for every one. If I recall correct, did @joshtriplett recommend to write virtio modules in rust, this issue is about is virtual I/O.

https://github.com/freemed/tty0tty is kernel module that doesn't need (special) hardware.

tty0tty is a null modem emulator. In fact an emulator of pairs of serial ports having connected on ends Transmit line to others end Receive line and vice versa. This is great for testing user applications that use a serial interface ( /dev/ttyS0, /dev/ttyACM0, /dev/ttyUSB0 ) With tty0tty you tell the to be tested applications to use /dev/tnt0 and /dev/tnt1.

tty0tty was not included in mainline linux, I do hope the rust implementation will.
I haven't done an implementation attempt since I had the idea back several months ago and unlikely I will bite the bullet on this in the next few months.
So feel free to make my wish come true.

Hi,

Visiting this report shows a scary

This branch is 71 commits ahead, 14138 commits behind torvalds:master.

I'm voluntering to reduce the amounts of commits behind torvalds

Please grant me the privilege to push to this git repository.

If rust-lang/rust#77916 lands in upstream rust, we'll need to change the target we compile with. The new target makes more sense anyways :-)

The current cargo command creates the default cargo output. this does not look nice in the makefile output

  CC      net/ipv6/ipv6_sockglue.o
   Compiling termcolor v1.1.0
  CC      sound/pci/hda/hda_proc.o       ] 15/69: termcolor
   Compiling strsim v0.8.0
   Compiling ansi_term v0.11.0
  CC      net/ipv4/tcp_input.o           ] 17/69: ansi_term
  CC      sound/pci/hda/hda_hwdep.o
   Compiling vec_map v0.8.2
  CC      net/ipv6/ndisc.o               ] 18/69: vec_map
   Compiling bindgen v0.54.0
   Compiling core v0.0.0 (/home/kloenk/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
  CC      sound/pci/hda/hda_intel.o      ] 20/69: core
  CC      net/ipv6/udp.o

This gives a clear indication to the user of the data structure that they cannot be safely moved.

Since synchronizing with v5.10 (#60) we are getting:

ld: warning: orphan section `.text.__rust_probestack' from `drivers/char/rust_example/rust_example.o' being placed in section `.text.__rust_probestack'
ld: warning: orphan section `.eh_frame' from `drivers/char/rust_example/rust_example.o' being placed in section `.eh_frame'

See e.g. https://github.com/Rust-for-Linux/linux/runs/1561327749

...so that the kernel module developer can pass it to the kernel APIs that use it.

There are multiple issues I see here:

• It should be possible for the user to configure the rust source directory independently of the rust sysroot
• Currently only sources from the library/ subdirectory are used. If it stays like this in the forseeable future, I would like to change the rustc_src variable to a rust_lib_src variable, which points directly to the library/ subdirectory. For example my distribution has an own package rustLibSrc, which will decrease the amount of downloads needed.

today @ojeda mentioned an error with GCC builds (example).

Doing a quick read through llvm's sources, this error diagnostic is called diag::err_asm_invalid_global_var_reg, it looks like it can be emitted from clang::Sema::ActOnVariableDeclarator based on clang::TargetInfo::validateGlobalRegisterVariable, it looks like there are target specific implementations only for i386 (32b x86). I can only repro such an error message when building for x86 with -m32 explicitly set: https://godbolt.org/z/YKcE9v

Perhaps the incorrect target triple is being passed? For am64, I'd have expected --target=aarch64-linux-gnu, but based on the error message, it seems perhaps --target=i386-linux-gnu is being used (or some other 32b x86 triple like i686-linux-gnu, or an additional flag like -m32 is being passed).

What would it take to make compiler_builtins be something that didn't need to manually be installed? There are a few approaches:

• For rustup to include it as a component, so that installation is easier (and it is automatically updated etc.).
• That the rust repo includes it (moonshot, but for those that need rust-src it is much more likely that they need it too).
• Removing it as a dependency by copying the needed builtins into the tree (the kernel does this for others, too).
• Removing it as a dependency by not using alloc (e.g. if for other reasons we end up with our own alloc).

I tried to find out how to detect thinks like if CONFIG_DEBUG_KERNEL is set. As I did not see a way, I implemented this way, but not sure if its a good way to handle this things. There for I only create the diff here, and no pr yet. This just passes every CONFIG_* to rustc as a cfg.

diff --git a/rust/kernel/build.rs b/rust/kernel/build.rs
index 0897186b3f92..2818bcb1b391 100644
--- a/rust/kernel/build.rs
+++ b/rust/kernel/build.rs
@@ -92,6 +92,26 @@ fn main() {
     println!("cargo:rerun-if-env-changed=RUST_BINDGEN_CFLAGS");

     let kernel_dir = "../../";
+    println!("cargo:rerun-if-changed={}/include/config/auto.conf", kernel_dir);
+    let file = std::fs::File::open(format!("{}/include/config/auto.conf", kernel_dir)).expect("could not open kernel config");
+    let file = std::io::BufReader::new(file);
+    use std::io::BufRead;
+    for line in file.lines() {
+        let line = line.unwrap();
+        if !line.contains("=") {
+            continue;
+        }
+        let line: Vec<&str> = line.split("=").collect();
+        if line.len() != 2 {
+            panic!();
+        };
+        let key = line[0];
+        let value = line[1].trim_matches('"');
+
+        println!("cargo:rustc-cfg={}=\"{}\"", key, value);
+    };
+
+
     let cflags = env::var("RUST_BINDGEN_CFLAGS").expect("Must be invoked from kernel makefile");

     let kernel_args = prepare_cflags(&cflags, &kernel_dir);

If a module contains a function with a large stack (example) it will fail to build as a loadable module on x86_64 with the following error:

  MODPOST Module.symvers
ERROR: modpost: "__rust_probestack" [drivers/char/rust_example_3.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:111: Module.symvers] Error 1
make[1]: *** Deleting file 'Module.symvers'
make: *** [Makefile:1455: modules] Error 2

(This is based on #52)

I think the problem is that the symbols from compiler_builtins aren't being exported.

We could store the bzImage on GitHub, and just download from there to make testing easier: https://docs.github.com/en/free-pro-team@latest/actions/guides/storing-workflow-data-as-artifacts

Some more docs under Documentation/rust would be nice before submission.

This error looks unrelated, but I can't build the kernel from this branch - here's the error I got:

$ make LLVM=1
arch/x86/Makefile:143: CONFIG_X86_X32 enabled but no binutils support
make[2]: execvp: /bin/sh: Argument list too long
scripts/Makefile.host:95: recipe for target 'scripts/basic/fixdep' failed
make[2]: *** [scripts/basic/fixdep] Error 127
Makefile:560: recipe for target 'scripts_basic' failed
make[1]: *** [scripts_basic] Error 2
Makefile:732: recipe for target 'include/config/auto.conf.cmd' failed
make: *** [include/config/auto.conf.cmd] Error 2
make: *** [include/config/auto.conf.cmd] Deleting file 'include/generated/autoconf.h'

I used a config that was working with master and just enabled the new Rust driver.

Is there any other info that's helpful for diagnosing this issue?

Compiling the current head of the rust branch failed for me. Here is my setup:

> rustup toolchain install nightly-2020-08-27
> rustup default nightly-2020-08-27
> rustup component add rust-src
> cat .config | grep -E '(RUST|CARGO)'
CONFIG_HAS_RUST=y
CONFIG_RUSTC_VERSION=14700
CONFIG_CARGO_VERSION=14700
CONFIG_RUST_EXAMPLE=y
CONFIG_RANDOM_TRUST_CPU=y
# CONFIG_RANDOM_TRUST_BOOTLOADER is not set
# CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT is not set
CONFIG_SYSTEM_TRUSTED_KEYRING=y
CONFIG_SYSTEM_TRUSTED_KEYS=""
# CONFIG_SECONDARY_TRUSTED_KEYRING is not set
> make LLVM=1
  ...
  CARGO     arch/x86/entry/vdso/out/libvdso-image.a
   Compiling core v0.0.0 (/home/$USER/.rustup/toolchains/nightly-2020-08-27-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   Compiling kernel v0.1.0 (/home/$USER/Code/rust-for-linux/rust/kernel)
   Compiling rustc-std-workspace-core v1.99.0 (/home/$USER/.rustup/toolchains/nightly-2020-08-27-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
   Compiling compiler_builtins v0.1.32
   Compiling alloc v0.0.0 (/home/$USER/.rustup/toolchains/nightly-2020-08-27-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc)
   Compiling bitflags v1.2.1
   Compiling shlex v0.1.1 (/home/$USER/Code/rust-for-linux/rust/shlex)
error[E0463]: can't find crate for `std`
  |
  = note: the `x86_64-linux-kernel` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: could not compile `shlex`.

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed
make[3]: *** [scripts/Makefile.build:318: arch/x86/entry/vdso/out/libvdso-image.a] Error 101
make[2]: *** [scripts/Makefile.build:518: arch/x86/entry/vdso] Error 2
make[1]: *** [scripts/Makefile.build:518: arch/x86/entry] Error 2
make: *** [Makefile:1838: arch/x86] Error 2

Is there something missing in Documentation/rust/quick-start.rst?

The plan of what will go into the first PR/RFC. Each will likely be a separate commit/patch. Not everything is strictly required, but good to write down anyway.

• Kbuild
• Kconfig
• Bindings / krustlib / ...
• Testing story (e.g. selftests, unit testing, related Kconfig entries, etc.)
• Other required changes in infrastructure
• First example driver (QEMU/virtio)
• Second example driver (ARM/RaspberryPi)

So far discussed in the LPC hackroom with @nickdesaulniers @geofft @joshtriplett @alex @cuviper @arndb Patrick McLean et. al.

IBM Z / LinuxONE is supported by Red Hat and Ubuntu, which means we should eventually support the s390x architecture.

Linux s390 targets with official Ubuntu binutils etc. support:

Linux arch  QEMU target    LLVM target  Ubuntu binutils           Example Rust triple
----------  -------------  -----------  ------------------------  -----------------------

s390        s390x-softmmu  SystemZ      binutils-s390x-linux-gnu  s390x-unknown-linux-gnu

As Alex suggests, it would be nice to put the # Report part into a JSON artifact or similar, so that we can then track/read them in an easier way.

While all Linux, QEMU, LLVM and Rust support SPARC to some degree, there is no official support from any major distribution (Ubuntu, Red Hat or even Debian). Furthermore, while Oracle and Fujitsu still sell servers, they seem to only support Solaris. Furthermore, there is no support for Clang/LLVM-built kernels. Therefore, this is an architecture we can probably skip. Nevertheless, if someone wants to add support, feel free to give it a go!

Linux sparc targets without official Ubuntu binutils etc. support:

Linux arch  QEMU target      LLVM target  Ubuntu binutils  Example Rust triple
----------  ---------------  -----------  ---------------  -------------------------

sparc       sparc-softmmu    Sparc        -                sparc-unknown-linux-gnu
sparc       sparc64-softmmu  Sparc        -                sparc64-unknown-linux-gnu

For 64-bit, one may use binutils-sparc64-linux-gnu from Ubuntu universe or Debian.

Currently we duplicate a bit of logic on the Rust side for our initcall handling.

Consider performing codegen instead to be able to reuse the C macros instead. This is basically the approach we took in rust/exports.c too. Even if may look ugly, it is best to avoid redoing parts of the C infrastructure.

This would also remove our need for the unstable global_asm!.

To ensure reproducible builds and no unintended updates even if a developer runs cargo on their own without one of the locking flags, pin all dependencies to an exact version, explicitly managing them from now on:

• bitflags is missing the minor and the patch number.
• bindgen is missing the patch number.

Some build systems (like nix) do not allow network access while building, but then provide a download phase, where network access is allowed.
For this to work with cargo, we would have to create a cargo vendor dir, and call cargo with the flags, to not update the index and use the vendor dir.

Currently the generated intra-doc links go to the official Rust docs webpage.

Consider generating core and alloc so that:

• It doesn't require internet (for local builds).
• It doesn't depend on another host (for kernel.org builds).
• They are consistent with the compiled crates (e.g. nightly Rust could have added features not present in the local version).

MIPS little-endian, both 32-bit and 64-bit, is supported by Debian, which means we should eventually support the mipsel and mips64el architectures.

Linux mips targets with official Ubuntu binutils etc. support:

Linux arch  QEMU target       LLVM target  Ubuntu binutils                   Example Rust triple
----------  ----------------  -----------  --------------------------------  -------------------------------

mips        mips-softmmu      Mips         binutils-mips-linux-gnu           mips-unknown-linux-gnu
mips        mipsel-softmmu    Mips         binutils-mipsel-linux-gnu         mipsel-unknown-linux-gnu
mips        mips64-softmmu    Mips         binutils-mips64-linux-gnuabi64    mips64-unknown-linux-gnuabi64
mips        mips64el-softmmu  Mips         binutils-mips64el-linux-gnuabi64  mips64el-unknown-linux-gnuabi64

#7 introduces the machinery to support kernel parameters, but there are some things to do:

• bool and i32 — #7
• u8, u16, u32, u64 and i16 — #82
• charp/string — #82 and #110
• invbool was added a long time ago but was only ever used by 2 modules or so: we decided not to support it — #82
• bint was added a long time ago, used by about 8 modules, but users should probably use bool properly instead.
• bool_enable_only was added in 2015, but it is used by 1 module only, so we can skip it for now.
• hexint was added in 2020 but only 1 amdgpu module uses it so far, so we can skip it for now. We could also consider having our own parser for the primitive types, accepting hex/oct/bin etc. automatically, rather than have different param types like this one.
• i128 and u128: we forbid code using 128-bit integers.
• i8, i64, usize and isize — #87
• Arrays — #110
• unsafe flag (taints kernel)
• hwparam flag + hwparam_type: probably another key in the dictionary, or use wrapper types.
• An easy interface to provide custom types/ops (create a trait for it etc.)

When compiling the crates as staticlib, the compiler generates the symbols based on GlobalAlloc; but it doesn't when asking for an rlib.

I assume it does it only when it needs to link a "final" product (executable, static library, etc.), but I haven't look how it actually works in rustc yet. I think it is reasonable to generate them in an rlib which overrides the allocator, but maybe they have a reason not to...

This architecture is becoming more popular as time passes and is on the forefront of open research, so it would be a fitting and welcome addition to provide its users with Rust support. In particular, the 64-bit one.

Linux riscv targets with official Ubuntu binutils etc. support:

Linux arch  QEMU target      LLVM target  Ubuntu binutils             Example Rust triple
----------  ---------------  -----------  --------------------------  -------------------

riscv       riscv64-softmmu  RISCV        binutils-riscv64-linux-gnu  riscv64gc-unknown-none-elf

In particular, there is no official 32-bit Ubuntu binutils package so far.

Although we don't get output unless we use -Z proc-macro-backtrace, it is a good idea to provide some more details like we do for some of the others, e.g. in:

fn expect_punct(it: &mut token_stream::IntoIter) -> char {
    if let TokenTree::Punct(punct) = it.next().unwrap() {
    ...

This unwrap() may fail if we find the end of the stream unexpectedly (because the user didn't pass the arguments that we expected).

This issue is for telling that there is no reason get scared upon seeing

This branch is 71 commits ahead, 14138 commits behind torvalds:master.

We, this repository, already are at version 5.10 of Linux, see also #70.

When we are at v5.11 we should have an open issue that tells so. It is for telling busy people that project is in very healthy state.

Armv7-A is becoming less popular given how cheap 64-bit chips are getting; however, we will have embedded 32-bit ARM around us for at least a decade, likely more. It is one of the key kernel architectures, too; and like x86, it is a good idea to support at least one 32-bit architecture to widen our tests and uncover possible issues etc.

Linux arm targets with official Ubuntu binutils etc. support:

Linux arch  QEMU target      LLVM target  Ubuntu binutils               Example Rust triple
----------  ---------------  -----------  ----------------------------  -------------------------

arm         arm-softmmu      ARM          binutils-arm-linux-gnueabihf  arm-unknown-linux-gnueabi
arm64       aarch64-softmmu  AArch64      binutils-aarch64-linux-gnu    aarch64-unknown-none

Currently, building with O=$something fails as auto.conf is search for in the source tree.
Also the arguments passed as cfg parsed from auto.conf can get bigger as the max argument length of linux.

PowerPC 64-bits little-endian is supported by Ubuntu, Red Hat and Debian, which means we should eventually support the ppc64el architecture.

Linux powerpc targets with official Ubuntu binutils etc. support:

Linux arch  QEMU target     LLVM target  Ubuntu binutils                 Example Rust triple
----------  --------------  -----------  ------------------------------  -------------------

powerpc     ppc-softmmu     PowerPC      binutils-powerpc-linux-gnu      powerpc-unknown-linux-gnu
powerpc     ppc64-softmmu   PowerPC      binutils-powerpc64le-linux-gnu  powerpc64-unknown-linux-gnu

When including the rust_example driver (not as module) I get a kernel panic:

[    0.487414][    T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc2+ #3
[    0.487414][    T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812d4
[    0.487414][    T1] RIP: 0010:__memcpy+0x12/0x20
[    0.487414][    T1] Code: 8c 94 00 00 74 0a c7 05 a8 8c 94 00 0f 00 00 00 c3 31 c0 c3 cc cc cc cc 0f 14
[    0.487414][    T1] RSP: 0000:ffffbcf0400133b8 EFLAGS: 00010202
[    0.487414][    T1] RAX: ffffbcf040013496 RBX: 00000000000003d2 RCX: 000000000000007a
[    0.487414][    T1] RDX: 0000000000000002 RSI: 3674fd8948f23948 RDI: ffffbcf040013496
[    0.487414][    T1] RBP: ffffbcf0400133d0 R08: 0000000000000000 R09: ffffbcf040013480
[    0.487414][    T1] R10: 0000000000000123 R11: ffffffff89997710 R12: ffffffff8a812258
[    0.487414][    T1] R13: ffffffff8a5eadd0 R14: ffffbcf040013480 R15: ffffbcf040013898
[    0.487414][    T1] FS:  0000000000000000(0000) GS:ffffa04c87a00000(0000) knlGS:0000000000000000
[    0.487414][    T1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.487414][    T1] CR2: 0000000000000000 CR3: 0000000005c0a000 CR4: 00000000000006f0
[    0.487414][    T1] Call Trace:
[    0.487414][    T1]  ? do_one_initcall+0xb8/0x250
[    0.487414][    T1]  ? alloc_pages_current+0x10a/0x1b0
[    0.487414][    T1]  ? allocate_slab+0xf7/0x4c0
[    0.487414][    T1]  ? ida_alloc_range+0x391/0x3d0
[    0.487414][    T1]  ? parse_one+0x53/0x270
[    0.487414][    T1]  ? do_initcall_level+0x88/0x88
[    0.487414][    T1]  ? parse_args+0x118/0x220
[    0.487414][    T1]  ? do_initcall_level+0x88/0x88
[    0.487414][    T1]  ? do_initcall_level+0x7e/0x88
[    0.487414][    T1]  ? do_initcalls+0x44/0x6d
[    0.487414][    T1]  ? kernel_init_freeable+0xd6/0x11d
[    0.487414][    T1]  ? rest_init+0xa0/0xa0
[    0.487414][    T1]  ? kernel_init+0x5/0x180
[    0.487414][    T1]  ? ret_from_fork+0x22/0x30
[    0.487414][    T1] Modules linked in:
[    0.515297][    T1] ---[ end trace 13ad6358da39c417 ]---
[    0.516114][    T1] RIP: 0010:__memcpy+0x12/0x20
[    0.516796][    T1] Code: 8c 94 00 00 74 0a c7 05 a8 8c 94 00 0f 00 00 00 c3 31 c0 c3 cc cc cc cc 0f 1f 44 00 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 <f3> 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 84
[    0.519649][    T1] RSP: 0000:ffffbcf0400133b8 EFLAGS: 00010202
[    0.520539][    T1] RAX: ffffbcf040013496 RBX: 00000000000003d2 RCX: 000000000000007a
[    0.521701][    T1] RDX: 0000000000000002 RSI: 3674fd8948f23948 RDI: ffffbcf040013496
[    0.522875][    T1] RBP: ffffbcf0400133d0 R08: 0000000000000000 R09: ffffbcf040013480
[    0.524036][    T1] R10: 0000000000000123 R11: ffffffff89997710 R12: ffffffff8a812258
[    0.525198][    T1] R13: ffffffff8a5eadd0 R14: ffffbcf040013480 R15: ffffbcf040013898
[    0.526361][    T1] FS:  0000000000000000(0000) GS:ffffa04c87a00000(0000) knlGS:0000000000000000
[    0.527666][    T1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.528626][    T1] CR2: 0000000000000000 CR3: 0000000005c0a000 CR4: 00000000000006f0
[    0.529790][    T1] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    0.530780][    T1] Kernel Offset: 0x8400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    0.530780][    T1] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---

Config and kernel console here: https://gist.github.com/Kloenk/aad17db1adc313ec49a51712c03060b0

For example, in file_operations we are forced to declare the functions as unsafe. It would be better if we could minimise the amount of unsafe code within the function by annotating just the unsafe operations.

Some ideas discussed in the LPC hackrooms worth exploring for the long-term:

• Rust support for some kind of way to annotate other kinds of "unsafety" for functions/contexts/scopes, e.g. unsafe(interrupt), unsafe(signal).

Create some way to run rust test.

Bindgen creates tests, for allignment. maybe we can test them somehow.

Printing support for levels and continuations was added in #120, but there are some features from the C side that we are missing:

• Specialized macros (~100k uses in the kernel just for dev_*() ones).
  • Sometimes they also provide the other features below.
• Dynamic debug (~12k uses in the kernel) for pr_debug() (different than pr_devel()).
  • Issue: #453.
• Rate limiting (~2k uses in the kernel).
• Custom formatting prefix (~800 uses in the kernel; of those ~400 are different than the usual "string: " fmt).
  • Perhaps we don't need this if we provide good enough specialized macros.
• Level 7 (devel) support (~700 uses in the kernel).
• "Once" support (~500 uses in the kernel).

Unstable features (including language, library, tools...) we currently use.

See as well:

• #354
• #514
• #408
• #572
• #355
• #350
• #398
• #353
• #349
• #397
• #396
• #1051
• #1080
• #1011
• #927
• #949
• #1029

Required (we almost certainly want them)

• cfg(no_fp_fmt_parse).

  • Tracking Issue: -.
  • Used by: Kbuild (core).
  • Status: added as unstable in 1.55 (rust-lang/rust#86048).

• cfg(no_global_oom_handling).

  • Tracking Issue: -.
  • Used by: Kbuild (alloc).
  • Status: added as unstable in 1.54 (rust-lang/rust#84266).

• cfg(no_rc).

  • Tracking Issue: -.
  • Used by: Kbuild (alloc).
  • Status: added as unstable in 1.66 (rust-lang/rust#89891).

• cfg(no_sync).

  • Tracking Issue: -.
  • Used by: Kbuild (alloc).
  • Status: added as unstable in 1.66 (rust-lang/rust#89891).

• feature(asm_const).

  • Tracking Issue: rust-lang/rust#93332.
  • Used by: tracepoint support / static keys / jump label patching (https://lore.kernel.org/rust-for-linux/[email protected]/, https://docs.kernel.org/staging/static-keys.html).
  • Status: stabilization FCP passed (rust-lang/rust#93332 (comment)).
  • Original experimental PR in the kernel side: #1084.

• feature(asm_goto).

  • Tracking Issue: rust-lang/rust#119364.
  • Used by: nothing yet in-tree, but it is needed for e.g. reimplementing jump label support (https://docs.kernel.org/staging/static-keys.html, #1084).
  • Status: added as unstable in 1.78 (rust-lang/rust#119365).
  • LKML: https://lore.kernel.org/rust-for-linux/[email protected]/
  • RFC: https://github.com/rust-lang/rfcs/blob/master/text/2873-inline-asm.md#asm-goto.

• feature(const_mut_refs) & feature(const_refs_to_static).

  • Tracking Issue: rust-lang/rust#57349 and rust-lang/rust#119618.
  • Used by: VFS, block layer... in order to fill const TABLEs (setting owner field to THIS_MODULE), as well as rust/kernel/module_param.rs (in the rust branch).
  • Status: see Ralf's comment at rust-lang/rust#119618 (comment). It is one of the subfeatures of const_fn.
  • Reduced example: https://godbolt.org/z/r58jP6YM4.
  • PR: rust-lang/rust#119614 (1.78).
  • PR including our VTABLE test case (tests/ui/consts/const-ref-to-static-linux-vtable.rs): rust-lang/rust#120932 (1.78).
  • Earlier (using static) Issue: rust-lang/rust#118447.
  • Earlier (using static) Related PR: rust-lang/rust#118324 (1.76) (if merged, and then other follow-up work Ralf has planned also lands, then the restriction could be relaxed).
  • Rust Zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/Consts.20pointing.20to.20mutable.20statics/near/404605842

• feature(derive_smart_pointer) (i.e. derive(SmartPointer)).

  • Tracking Issue: rust-lang/rust#123430.
  • Used by: Arc.
  • Status: implementation from @wedsonaf at rust-lang/rust#123472.
  • It is an alternative ("hooks/customization points") to having to stabilize other unstable features that would be otherwise needed to implement our custom Arc.
  • RFC: rust-lang/rfcs#3621.
  • RFC (one of the solutions for the unsoundness issue in the main RFC): rust-lang/rust#125048.
  • Cc: @wedsonaf (PoC), @Darksonn (RFC), @Veykril (RFC).
  • Meeting/discussion document: https://hackmd.io/OCz8EfzrRXeogXEDcOrL2w.
  • Rust Zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202024-03-06/near/431156003.
  • Rust Zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/425075-rust-for-linux/topic/meeting.202024-04-03/near/431148847.
  • Related: rust-lang/rust#125072 (1.80).

• feature(doc_cfg).

  • Tracking Issue: rust-lang/rust#43781.
  • Used by: rust/kernel/lib.rs.
  • Status: it looks like the feature will get stabilized, although there is still discussions around several bits, e.g. about automatically inferring doc(cfg(...)) from the cfg(...) (to avoid duplication) etc. See also #447.

• feature(impl_trait_in_assoc_type).

  • Tracking Issue: rust-lang/rust#63063 (the tracking issue is the original one before it got split from that one in rust-lang/rust#110237).
  • Used by: rnull (https://lore.kernel.org/rust-for-linux/[email protected]/).
  • Status: ?.

• feature(offset_of_nested).

  • Tracking Issue: rust-lang/rust#120140.
  • Used by: Binder (in one place: https://lore.kernel.org/rust-for-linux/CAH5fLgjP98pS1wsP=YXP5Yr79Y62VF7XPKjbj+G75B3SOFt80g@mail.gmail.com/) and possibly elsewhere in the future.
  • Status: added as unstable in 1.77 when the single-field one (offset_of) got stabilized (rust-lang/rust#118799).

• feature(register_tool).

  • Tracking Issue: rust-lang/rust#66079.
  • Used by: klint #958.
  • Status: waiting for RFC to clarify use cases.

• __rust_no_alloc_shim_is_unstable.

  • Tracking Issue: ?.
  • Used by: rust/kernel/allocator.rs.
  • Status: added as unstable in 1.71 (rust-lang/rust#86844); see rust-lang/rust#73632 as well.

• -Zbinary_dep_depinfo=y.

  • Tracking Issue: rust-lang/rust#63012.
  • Used by: Kbuild.
  • Status: we could get around it by making the build system more complicated (particularly if the kernel does not upgrade the minimum Make version), but it would be best to avoid that.

• -Zbranch-protection.

  • Tracking Issue: rust-lang/rust#113369.
  • Used by: arm64's CONFIG_ARM64_BTI_KERNEL etc.
  • Status: Unknown, potentially to be merged with -Zcf-protection -- see https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.60-Zbranch-protection.60.20stability/near/391152508.

• -Zcf-protection=branch (CET).

  • Tracking Issue: rust-lang/rust#93754.
  • Used by: x86_64's CONFIG_X86_KERNEL_IBT (https://lore.kernel.org/rust-for-linux/[email protected]/).
  • Status: implemented in 1.60 (rust-lang/rust#93439).

• -Zdebuginfo-compression.

  • Tracking Issue: rust-lang/rust#120953.
  • Used by: Kbuild.
  • Status: added as unstable in 1.74 (rust-lang/rust#115358).

• -Zdwarf-version.

  • Tracking Issue: rust-lang/rust#103057.
  • Used by: Kbuild.
  • Status: added as unstable in 1.64 (rust-lang/rust#98350).

• -Zfixed-x18.

  • Tracking Issue: -.
  • Used by: arm64's shadow call stack (SCS) support.
  • Status: added as unstable in 1.80 rust-lang/rust#124655.

• -Zfunction-return=thunk-extern.

  • Tracking Issue: rust-lang/rust#116853.
  • Used by: x86_64's CONFIG_RETHUNK.
  • Status: Implementation PR at rust-lang/rust#116892.

• -Zinstrument-mcount.

  • Tracking Issue: ? rust-lang/rust#84605 (#[no_coverage]).
  • Used by: ftrace, probably/eventually.
  • Status: Broken? (rust-lang/rust#92109). Perhaps related to the new pass manager? Closed PR: rust-lang/rust#96238.

• -Zno-jump-tables.

  • Tracking Issue: rust-lang/rust#116592.
  • Used by: x86_64's CONFIG_X86_KERNEL_IBT (https://lore.kernel.org/rust-for-linux/[email protected]/).
  • Status: Unknown, but in principle it should be possible to stabilize.
  • PR: rust-lang/rust#105812 (1.68).
  • PR: rust-lang/rust#116593 (1.75).

• -Zrandomize-layout (and -Zlayout-seed=<seed>).

  • Tracking Issue: rust-lang/rust#106764.
  • Used by: security, probably/eventually.
  • Status: unknown. The use case of the MCP was debugging (e.g. detecting invalid layout assumptions), rather than security (which the kernel uses under some configurations -- see CONFIG_RANDSTRUCT*).

• -Zsanitizer=kcfi & -Zsanitizer-cfi-normalize-integers (KCFI).

  • Tracking Issue (KCFI): rust-lang/rust#123479.
  • Tracking Issue (CFI): rust-lang/rust#89653.
  • Tracking Issue (sanitizers in general): rust-lang/rust#39699.
  • Used by: arm32/arm64/RISC-V/x86_64's KCFI (CONFIG_CFI_CLANG).
  • Status: ready for use in 1.79 (https://lore.kernel.org/rust-for-linux/CAGSQo024u1gHJgzsO38Xg3c4or+JupoPABQx_+0BLEpPg0cOEA@mail.gmail.com/), implemented with some key differences vs. CFI -- benchmarks needed / report regressions (https://lore.kernel.org/rust-for-linux/CAOcBZOS2kPyH0Dm7Fuh4GC3=v7nZhyzBj_-dKu3PfAnrHZvaxg@mail.gmail.com/).
  • KCFI PRs: https://github.com/rust-lang/rust/pulls?q=is%3Apr+cfi+label%3APG-exploit-mitigations+-label%3Arollup (1.58..1.79).
  • KCFI will require -Cpanic=abort until LLVM's invoke supports KCFI bundles: rust-lang/rust#123106 (comment).
  • KCFI Rust docs: https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/sanitizer.html#kernelcontrolflowintegrity.
  • KCFI RFC: rust-lang/rfcs#3296.
  • KCFI PR on the kernel side: #1034 (https://github.com/maurer/linux/commits/kcfi/).
  • @maurer's design doc: Fixing CFI VTables.
  • Cc: @rcvalle @maurer.

• -Ztune-cpu=generic.

  • Tracking Issue: ?.
  • Used by: x86's Makefile.
  • Status: unknown (no tracking issue?).

• -Zub-checks (cfg(ub_checks)).

  • Tracking Issue: rust-lang/rust#123499.
  • Used by: Kbuild.
  • Status: added as unstable in 1.79 (rust-lang/rust#123411).

• rustdoc's --no-run (-Zunstable-options).

  • Tracking Issue: rust-lang/rust#87022.
  • Used by: KUnit test generation.
  • Status: no recent update.

• rustdoc's --test-builder (-Zunstable-options).

  • Tracking Issue: rust-lang/rust#102981.
  • Used by: KUnit test generation.
  • Status: it appears it is not intended to be stabilized.

• Remaining target features unknown to rustc.

  • Tracking Issue: rust-lang/rust#44839.
  • Used by: Kbuild.
  • Status: unclear. Alternatively, we could use a way to suppress the warning for unknown features + get a promise that all features are disabled by default (so that we can enable the ones we need only). See c5eae3a, 9a9d6ee, rust-lang/rust#96472 and rust-lang/rust#87402 for context.

• Target specification file or enough command-line flags to replace it.

  • Tracking Issue: ?.
  • Used by: Kbuild.
  • Status: the target specification file is fairly tied to LLVM, thus it is unclear if something like it can be ever stabilized. Stabilizing command-line flags appears to be the likely path forward. In cases where the flag would change the ABI, a "global target feature" concept (e.g. -Cglobal-target-feature=) could be useful, i.e. a target feature that is required to be set the same way for all compilation units (without requiring a new target). In other words, using flags to create combinations of targets instead of requiring a different for each combination. See -Cfixed-x18 discussion as well.

Nice to have (not critical, we could workaround if needed, etc.)

• --extern force:.

  • Tracking Issue: rust-lang/rust#111302.
  • Used by: possibly Kbuild (as a workaround for "empty" Rust files, see commit ded103c ("kbuild: rust: force alloc extern to allow "empty" Rust files")).
  • Status: it can be dropped when (at least) new_uninit is dropped. There may be other workarounds. Added as unstable in 1.71 (rust-lang/rust#109421).

• feature(associated_type_defaults).

  • Tracking Issue: rust-lang/rust#29661.
  • Used by: file_operations.rs to simplify boilerplate needed by drivers, as well as pci.rs (e.g. https://lore.kernel.org/rust-for-linux/[email protected]/).
  • Status: there is no recent activity in the tracking issue, but we could add back the boilerplate.

• feature(const_refs_to_cell).

  • Tracking Issue: rust-lang/rust#80384.
  • Used by: rust/kernel/driver.rs, offset_of! (if feature(offset_of) does not pan out).
  • Status: stabilization has unsolved issues with its interaction with const_heap.

• feature(const_trait_impl).

  • Tracking Issue: rust-lang/rust#67792.
  • Used by: rust/kernel/driver.rs (e.g. see _new_id_array!, define_id_array! and define_id_table! in https://lore.kernel.org/rust-for-linux/[email protected]/).
  • Status: "This RFC has not yet been accepted. It is being implemented on a provisional basis to evaluate the potential fallout.". Moreover, the syntax is undecided/temporary.

• feature(c_size_t)

  • Tracking Issue: rust-lang/rust#88345.
  • Used by: rust/kernel/file.rs (so far, but could be anywhere in the abstractions).
  • Status: unknown, but core_ffi_c got stabilized in 1.64 (rust-lang/rust#98315) and c_{s,}size_t are now in core::ffi since 1.61 (rust-lang/rust#94503). We can always go back to c_types.rs.

• feature(duration_constants).

  • Tracking Issue: rust-lang/rust#57391.
  • Used by: rust/kernel/delay.rs.
  • Status: the FCP stalled, and there was discussion around other alternatives (e.g. a TimeUnits to do things like 2.seconds()). We can always use our own constants.

• feature(new_uninit).

  • Tracking Issue: rust-lang/rust#63291.
  • Used by: the pin-init API.
  • Status: FCP completed.
  • @tgross35 said:

    Last I heard the libs team was looking for a way to have something like a builder pattern rather than all the permutations of new, new_uninit, new_uninit_zeroed, try_new, etc. I proposed an incomplete API somewhere (libs team repo?) but it didn’t go anywhere

  • Alternative (proposed by Benno): https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/dropping.20the.20.60new_uninit.60.20feature/near/435522549.

• feature(ptr_metadata) (core::ptr::metadata and core::ptr::from_raw_parts_mut functions).

  • Tracking Issue: rust-lang/rust#81513.
  • Used by: Arc, and potentially by impl_zeroable! to include pointers to DSTs when their metadata is Zeroable via the Pointee trait.
  • Status: in discussion, design concerns.
  • Alternatives: rust-lang/rust#96283 (1.75, which we will use soon -- patch at https://lore.kernel.org/rust-for-linux/[email protected]/) and rust-lang/libs-team#111.

• -Zcrate-attr.

  • Tracking Issue: ? (there is a rust-lang/rust#52355).
  • Used by: all kernel modules. It could also be used to solve rust-lang/rfcs#3226 as long as the attributes handle the local file case.
  • Status: unlikely to get stabilized (although in the custom logo RFC it was discussed), but we only use it for convenience.

• -Zfunction-sections (in rustc, it applies to data too).

  • Tracking Issue: None (it comes from 2014, pre-1.0 rustc: rust-lang/rust@6b130e3).
  • Used by: Makefile (under CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, which is experimental so far).
  • Status: unknown. It would be good to have, especially if the C side starts using it routinely.

• -Zunpretty=expanded.

  • Tracking Issue: rust-lang/rust#43364.
  • Used by: developers through Kbuild.
  • Status: no recent progress. It is a feature that should be in stable compilers, but it is not critical for building the kernel (we could use RUSTC_BOOTSTRAP=1 only for the target that uses it, if needed).

• -Zuse-sync-unwind=n.

  • Tracking Issue: ?.
  • Used by: arm64.
  • Status: added as unstable in 1.77 (rust-lang/rust#117744). We do not need it as long as n remains the default.
  • From: https://lore.kernel.org/rust-for-linux/CAH5fLgg0yGbuHnMbMB103Zssg4KSfXUR3kvhr0kuqTSah=6kWg@mail.gmail.com/

Low priority (we will likely not use them in the end)

• feature(allocator_api).

  • Tracking Issue: rust-lang/rust#32838.
  • Used by: almost all modules.
  • Status: we have an in-tree alloc fork, but we are likely dropping it (https://lore.kernel.org/rust-for-linux/[email protected]/); otherwise: still quite open.

• feature(coerce_unsized) & feature(unsize) (core::ops::CoerceUnsized and core::marker::Unsize traits).

  • Tracking Issue: rust-lang/rust#18598.
  • Used by: Arc.
  • Status: we may use feature(derive_smart_pointer) instead to avoid depending on Arc's needed features; otherwise: "the CoerceUnsized trait is unstable and we wish to revisit its design before stabilizing, so for now only stdlib types can be unsized" + there are unsoundness issues, see rust-lang/rust#68015 and rust-lang/rust#85099. See https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/rust-for-linux.20custom.20arc.20unstable.20feature.20requirements.

• feature(dispatch_from_dyn) (core::ops::DispatchFromDyn trait).

  • Tracking Issue: None (internal to the compiler).
  • Used by: Arc.
  • Status: we may use feature(derive_smart_pointer) instead to avoid depending on Arc's needed features; otherwise: see https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/rust-for-linux.20custom.20arc.20unstable.20feature.20requirements.

• feature(pointer_is_aligned) (is_aligned_to).

  • Tracking Issue: rust-lang/rust#96284.
  • Used by: eventually by FromBytes (VFS abstractions, #1038).
  • Status: the first half (is_aligned()) got stabilized in 1.79 (rust-lang/rust#121948). is_aligned_to() may be stabilized, but it needs to be justified.

• feature(more_fallible_allocation_methods).

  • Tracking Issue: rust-lang/rust#86942.
  • Used by: alloc.
  • Status: we have an in-tree alloc fork, but we are likely dropping it (https://lore.kernel.org/rust-for-linux/[email protected]/); otherwise: unknown.

• feature(receiver_trait) (core::ops::Receiver trait).

  • Tracking Issue: None (internal to the compiler).
  • Used by: Arc.
  • Status: we may use feature(derive_smart_pointer) instead to avoid depending on Arc's needed features; otherwise: see https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/rust-for-linux.20custom.20arc.20unstable.20feature.20requirements. Another potential solution might be feature(arbitrary_self_types) (rust-lang/rust#44874), though it has different tradeoffs.
  • RFC: rust-lang/rfcs#3519 (with feedback at rust-lang/rfcs#3519 (comment) and https://hackmd.io/z4n40072Tqy8MhQPZn0N-g).

Done (stabilized, not needed anymore, etc.)

• --check-cfg.

  • Tracking Issue: rust-lang/rust#82450.
  • Used by: Kbuild.
  • Status: stabilized in 1.79 (rust-lang/rust#123501).
  • Tested for the kernel in 1.77, feedback at: rust-lang/rust#82450 (comment).
  • PR from feedback (avoid printing all the possible cfgs): rust-lang/rust#121202 (1.78).
  • PR from feedback (use CARGO_CRATE_NAME instead of CARGO as a better heuristic for Cargo diagnostics): rust-lang/rust#121237 (1.78).

• feature(alloc_error_handler).

  • Tracking Issue: rust-lang/rust#51540.
  • Used by: -.
  • Status: marked as done since we use no_global_oom_handling.

• feature(bench_black_box).

  • Tracking Issue: rust-lang/rust#64102.
  • Used by: samples/rust/rust_stack_probing.rs.
  • Status: stabilized in 1.66 (rust-lang/rust#102232).

• feature(concat_idents).

  • Tracking Issue: rust-lang/rust#29599.
  • Used by: drivers/android/defs.rs in the past, nothing now.
  • Status: no plan to stabilize, using the paste crate is an alternative (or, in general, generating code). We ended up using a proc macro on our side #826.

• feature(const_fn_transmute).

  • Tracking Issue: rust-lang/rust#53605.
  • Used by: rust/kernel/str.rs.
  • Status: stabilized in 1.56 (rust-lang/rust#85769). It is one of the subfeatures of const_fn.

• feature(const_fn_trait_bound).

  • Tracking Issue: rust-lang/rust#57563.
  • Used by: rust/kernel/file_operations.rs and rust/kernel/module_param.rs.
  • Status: stabilized in 1.61 (rust-lang/rust#93827). No tracking issue of its own. It is one of the subfeatures of const_fn.

• feature(const_maybe_uninit_zeroed).

  • Tracking Issue: rust-lang/rust#91850.
  • Used by: PHY (https://lore.kernel.org/rust-for-linux/[email protected]/).
  • Status: stabilized in 1.75 (rust-lang/rust#116218).

• feature(const_panic).

  • Tracking Issue: rust-lang/rust#51999.
  • Used by: rust/kernel/print.rs.
  • Status: stabilized in 1.57 (rust-lang/rust#89508). It is one of the subfeatures of const_fn.

• feature(const_ptr_offset_from).

  • Tracking Issue: rust-lang/rust#92980.
  • Used by: rust/kernel/driver.rs.
  • Status: stabilized in 1.65 (rust-lang/rust#96240).

• feature(const_raw_ptr_deref)

  • Tracking issue: rust-lang/rust#51911.
  • Used by: rust/kernel/str.rs.
  • Status: replaced on our side with const_fn_transmute since that was getting stabilized sooner.

• feature(const_unreachable_unchecked).

  • Tracking Issue: rust-lang/rust#53188.
  • Used by: rust/kernel/str.rs.
  • Status: stabilized in 1.57 (rust-lang/rust#89509). It is one of the subfeatures of const_fn.

• feature(core_ffi_c)

  • Tracking Issue: rust-lang/rust#94501.
  • Used by: bindings, module!, etc.
  • Status: stabilized in 1.64 (rust-lang/rust#98315).

• feature(core_panic).

  • Tracking Issue: None (internal to the compiler).
  • Used by: rust/build_assert.rs.
  • Status: not used anymore; replaced with panic!("{}", msg) (2021 edition, allowed in const context since rust-lang/rust#88954).

• feature(explicit_generic_args_with_impl_trait)

  • Tracking Issue: rust-lang/rust#83701.
  • Used by: pinned-init.
  • Status: stabilized in 1.63 (rust-lang/rust#96868).

• feature(generic_associated_types).

  • Tracking Issue: rust-lang/rust#44265.
  • Used by: rust/kernel/types.rs (PointerWrapper), rust/kernel/file_operations.rs (IoctlHandler).
  • Status: stabilized in 1.65 (rust-lang/rust#96709).

• feature(global_asm).

  • Tracking Issue: rust-lang/rust#35119.
  • Used by: all modules, due to code generated by the rust/module.rs proc macro.
  • Status: stabilized in 1.59 (rust-lang/rust#91728) -- we may want to avoid doing things this way anyway. See #77.

• feature(let_else).

  • The kernel's coding style avoids nesting/identation where possible, i.e. keeping the success path as the main path. let_else helps naturally with that (when applicable).
  • Tracking Issue: rust-lang/rust#87335.
  • Used by: rust/macros/paste.rs and potentially everywhere.
  • Status: stabilized in 1.65 (rust-lang/rust#93628).

• feature(maybe_uninit_extra).

  • Tracking Issue: rust-lang/rust#63567.
  • Used by: rust/kernel/miscdev.rs.
  • Status: stabilized in 1.60 (rust-lang/rust#92768) (non-const only, which is the only part we need).

• feature(offset_of) (single-field, i.e. no enum, no nested).

  • Tracking Issue: rust-lang/rust#106655.
  • Used by: rust/kernel/workqueue.rs and kernel/kasync/executor/workqueue.rs (https://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git/commit/?h=for-6.7-rust-bindings&id=7324b88975c525a013ae0db747df97924ce80675).
  • Status: stabilized in 1.77 (rust-lang/rust#118799).

• feature(pin_macro).

  • Tracking Issue: rust-lang/rust#93178.
  • Used by: stack_pin_init! and stack_try_pin_init!.
  • Status: stabilized in 1.68 (rust-lang/rust#103800).

• feature(try_reserve).

  • Tracking Issue: rust-lang/rust#48043.
  • Used by: rust/kernel/lib.rs.
  • Status: stabilized in 1.57 (rust-lang/rust#87993).

• -Zallow-features.

  • Cargo reference: https://doc.rust-lang.org/cargo/reference/unstable.html#allow-features.
  • Used by: Kbuild.
  • Status: although it will never get stabilized, we will not need it as soon as all other features we need get stabilized, thus we mark it as done.

• -Zbuild-std.

  • Cargo reference: https://doc.rust-lang.org/cargo/reference/unstable.html#build-std.
  • WG: https://github.com/rust-lang/wg-cargo-std-aware.
  • Used by: Kbuild (only for the rusttest target, back when we had a custom alloc).
  • Status: marked as done since we do not have a custom alloc anmore. The actual progress is not clear. See #572.

• -Zsplit-dwarf-kind=split.

  • Tracking Issue: ?.
  • Used by: potentially Kbuild, but only if split stops being the default.
  • Status: added as unstable in 1.59 (rust-lang/rust#89819). As long as split is the default, we will not need it.

• -Zsymbol-mangling-version=v0.

  • Tracking Issue: rust-lang/rust#60705.
  • Used by: rust/exports.c.
  • Status: stabilized in 1.59 (rust-lang/rust#90128). It will also be the new default, so this is a no-brainer (rust-lang/rust#89917).

While x86 (i.e. 32-bit) will become less important over time, it is a key architecture of the kernel (and the original one, too). In addition, it is a non-64 bit target (which helps widening our tests to uncover potential issues) and it is a target that pretty much everyone can natively run. Thus we should support it.

Linux x86 targets with official Ubuntu binutils etc. support:

Linux arch  QEMU target     LLVM target  Ubuntu binutils            Example Rust triple
----------  --------------  -----------  -------------------------  ----------------------

x86         i386-softmmu    X86          binutils-i686-linux-gnu    i686-unknown-linux-gnu
x86         x86_64-softmmu  X86          binutils-x86-64-linux-gnu  x86_64-linux-kernel

Currently building several built-in modules does not work since shared crates are re-compiled (and therefore re-linked) for each module.

When we get an actual driver somewhere else, move the example one(s) into samples/.

The other 3 dummy copies (used for the GitHub CI) should either be removed or, better, moved into wherever we start putting Rust-related tests (e.g. rust/tests/?), eventually; and refactor them so that the test can run independently of GitHub Actions.

The stack size is 8KB, having a local variable of 8KB+32 bytes takes it over the edge.

I have seen failures on debug builds for this, for example, https://github.com/Rust-for-Linux/linux/runs/2107043283?check_suite_focus=true -- it has the following error:

[   13.127113] Large array has length: 1028
[   13.131438] BUG: stack guard page was hit at (____ptrval____) (stack is (____ptrval____)..(____ptrval____))
[   13.131438] kernel stack overflow (double-fault): 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI

For now I'm reducing the variable size in #104 to work around this. Please fix if you need it to be bigger to ensure probestack is properly tested.