rust-for-linux / linux Goto Github PK
View Code? Open in Web Editor NEWThis project forked from torvalds/linux
Adding support for the Rust language to the Linux kernel.
Home Page: https://rust-for-linux.com
License: Other
This project forked from torvalds/linux
Adding support for the Rust language to the Linux kernel.
Home Page: https://rust-for-linux.com
License: Other
Some more docs under Documentation/rust
would be nice before submission.
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
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.
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.
Currently building several built-in modules does not work since shared crates are re-compiled (and therefore re-linked) for each module.
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.
So far discussed in the LPC hackroom with @nickdesaulniers @geofft @joshtriplett @alex @cuviper @arndb Patrick McLean et. al.
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....so that the kernel module developer can pass it to the kernel APIs that use it.
Printing support for levels and continuations was added in #120, but there are some features from the C side that we are missing:
dev_*()
ones).
pr_debug()
(different than pr_devel()
).
"string: " fmt
).
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
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);
Some ideas discussed in the LPC hackrooms worth exploring for the long-term:
unsafe(interrupt)
, unsafe(signal)
.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
Create some way to run rust test.
Bindgen creates tests, for allignment. maybe we can test them somehow.
Line 119 in 304ee69
There are multiple issues I see here:
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.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.
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!
.
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
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 gives a clear indication to the user of the data structure that they cannot be safely moved.
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.
Currently the generated intra-doc links go to the official Rust docs webpage.
Consider generating core
and alloc
so that:
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 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.
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
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 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.
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).
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.
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
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.
What would it take to make compiler_builtins
be something that didn't need to manually be installed? There are a few approaches:
rust
repo includes it (moonshot, but for those that need rust-src
it is much more likely that they need it too).alloc
(e.g. if for other reasons we end up with our own alloc
).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
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
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?
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.
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).
Unstable features (including language, library, tools...) we currently use.
See as well:
cfg(no_fp_fmt_parse)
.
core
). cfg(no_global_oom_handling)
.
alloc
). cfg(no_rc)
.
alloc
). cfg(no_sync)
.
alloc
).Clippy's configuration file.
Clippy's CLIPPY_CONF_DIR
environment variable.
.clippy.toml
). feature(asm_const)
with support for raw pointers.
feature(asm_goto)
.
feature(const_mut_refs)
& feature(const_refs_to_static)
.
const TABLE
s (setting owner
field to THIS_MODULE
), as well as rust/kernel/module_param.rs
(in the rust
branch).const_mut_refs
stabilized in 1.83 (rust-lang/rust#129195; reference: rust-lang/reference#1590); const_refs_to_static
stabilization proposal at rust-lang/rust#128183. It is one of the subfeatures of const_fn
.VTABLE
test case (tests/ui/consts/const-ref-to-static-linux-vtable.rs
): rust-lang/rust#120932 (1.78). feature(derive_smart_pointer)
(i.e. derive(SmartPointer)
).
Arc
.Arc
.feature(pin_coerce_unsized_trait)
, one of the solutions for the unsoundness issue in the main RFC): rust-lang/rust#125048 (1.82). feature(doc_cfg)
.
rust/kernel/lib.rs
.doc(cfg(...))
from the cfg(...)
(to avoid duplication) etc. See also #447. feature(impl_trait_in_assoc_type)
.
rnull
(https://lore.kernel.org/rust-for-linux/[email protected]/). feature(register_tool)
.
klint
#958. -Zbinary_dep_depinfo=y
.
-Zbranch-protection
.
CONFIG_ARM64_BTI_KERNEL
etc.-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).
CONFIG_X86_KERNEL_IBT
(https://lore.kernel.org/rust-for-linux/[email protected]/). -Zdebuginfo-compression
(including zstd
support in Rust binaries' bundled LLVM).
zstd
support is used in Android, where it currently warns, see commit dbef181 ("kbuild: rust: use -Zdebuginfo-compression
"). -Zdirect-access-external-data={yes,no}
(Clang's -fdirect-access-external-data
).
-Zdwarf-version
.
-Zfixed-x18
.
-Zfunction-return=thunk-extern
.
CONFIG_MITIGATION_RETHUNK
. -Zinstrument-mcount
.
#[no_coverage]
). -Zno-jump-tables
.
CONFIG_X86_KERNEL_IBT
(https://lore.kernel.org/rust-for-linux/[email protected]/). -Zpatchable-function-entry
support (GCC's and Clang's -fpatchable-function-entry
), as well as the patchable_function_entry
function attribute.
-Zrandomize-layout
(and -Zlayout-seed=<seed>
).
CONFIG_RANDSTRUCT*
). -Zsanitizer=kcfi
& -Zsanitizer-cfi-normalize-integers
(KCFI).
CONFIG_CFI_CLANG
).-Cpanic=abort
until LLVM's invoke
supports KCFI bundles: rust-lang/rust#123106 (comment). -Ztune-cpu=generic
.
Makefile
. rustdoc
's --generate-link-to-definition
(-Zunstable-options
).
[references]
link from doc/source view could be nice to get). rustdoc
's --no-run
(-Zunstable-options
).
rustdoc
's --test-builder
(-Zunstable-options
).
ignore
, etc.) -- discussed with @GuillaumeGomez, we will write an issue with details about what could work for us. Remaining target features unknown to rustc
.
Target specification file or enough command-line flags to replace it.
-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.As many required bits done in the Rust version of the upcoming Debian Stable (Trixie).
--extern force:
.
alloc
extern to allow "empty" Rust files")).new_uninit
is dropped. There may be other workarounds. Added as unstable in 1.71 (rust-lang/rust#109421). feature(associated_type_defaults)
.
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]/). feature(box_uninit_write)
.
unsafe
block in Box<T>::new()
(BoxExt
). feature(const_trait_impl)
.
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]/). feature(c_size_t)
rust/kernel/file.rs
(so far, but could be anywhere in the abstractions).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)
.
rust/kernel/delay.rs
.TimeUnits
to do things like 2.seconds()
). We can always use our own constants. feature(ptr_metadata)
(core::ptr::metadata
and core::ptr::from_raw_parts_mut
functions).
Arc
, and potentially by impl_zeroable!
to include pointers to DSTs when their metadata is Zeroable
via the Pointee
trait. -Zcrate-attr
.
-Zfunction-sections
(in rustc
, it applies to data too).
rustc
: rust-lang/rust@6b130e3).Makefile
(under CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
, which is experimental so far). -Zub-checks
(cfg(ub_checks)
).
-Cdebug-assertions
, but not stabilizing this means one cannot enable/disable each of them independently. -Zunpretty=expanded
.
RUSTC_BOOTSTRAP=1
only for the target that uses it, if needed). -Zuse-sync-unwind=n
.
n
remains the default. feature(allocator_api)
.
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).
Arc
.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).
Arc
.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
).
FromBytes
(VFS abstractions, #1038).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)
.
alloc
.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).
Arc
.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. __rust_no_alloc_shim_is_unstable
.
rust/kernel/allocator.rs
at the moment, but we will not need when the allocator series goes in: https://lore.kernel.org/rust-for-linux/6HIL4hSg3hOCh5IDDOtdEaEy89ZksSJmSLNiKrSvpu2Q78wA5KdrCCrcPSD_p4jB7IlmVRyVBnvBllU4irzuYgpQJOBtwUInAKdOibtRjVc=@protonmail.com/, Björn says:
This can be removed too. liballoc needed it for us to acknowledge that we were linking liballoc in a way that isn't guaranteed to be stable, but now that we are removing liballoc entirely, this static is no longer necessary.
--check-cfg
.
cfg
s): rust-lang/rust#121202 (1.78).CARGO_CRATE_NAME
instead of CARGO
as a better heuristic for Cargo diagnostics): rust-lang/rust#121237 (1.78). feature(alloc_error_handler)
.
no_global_oom_handling
. feature(asm_const)
.
feature(bench_black_box)
.
samples/rust/rust_stack_probing.rs
. feature(concat_idents)
.
drivers/android/defs.rs
in the past, nothing now.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)
.
rust/kernel/str.rs
.const_fn
. feature(const_fn_trait_bound)
.
rust/kernel/file_operations.rs
and rust/kernel/module_param.rs
.const_fn
. feature(const_maybe_uninit_zeroed)
.
feature(const_panic)
.
rust/kernel/print.rs
.const_fn
. feature(const_ptr_offset_from)
.
rust/kernel/driver.rs
. feature(const_raw_ptr_deref)
rust/kernel/str.rs
.const_fn_transmute
since that was getting stabilized sooner. feature(const_refs_to_cell)
.
rust/kernel/driver.rs
, offset_of!
(if feature(offset_of)
does not pan out). feature(const_unreachable_unchecked)
.
rust/kernel/str.rs
.const_fn
. feature(core_ffi_c)
module!
, etc. feature(core_panic)
.
rust/build_assert.rs
.panic!("{}", msg)
(2021 edition, allowed in const context since rust-lang/rust#88954). feature(explicit_generic_args_with_impl_trait)
pinned-init
. feature(generic_associated_types)
.
rust/kernel/types.rs
(PointerWrapper
), rust/kernel/file_operations.rs
(IoctlHandler
). feature(global_asm)
.
rust/module.rs
proc macro. feature(let_else)
.
let_else
helps naturally with that (when applicable).rust/macros/paste.rs
and potentially everywhere. feature(maybe_uninit_extra)
.
rust/kernel/miscdev.rs
. feature(new_uninit)
.
pin-init
APIbox_uninit_write
(which we could use to avoid an unsafe
block, but it was replaced for the time being) and new_zeroed_alloc
.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
feature(offset_of)
(single-field, i.e. no enum
, no nested).
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). feature(offset_of_nested)
.
feature(pin_macro)
.
stack_pin_init!
and stack_try_pin_init!
. feature(try_reserve)
.
rust/kernel/lib.rs
. -Zallow-features
.
-Zbuild-std
.
rusttest
target, back when we had a custom alloc
).alloc
anmore. The actual progress is not clear. See #572. -Zsplit-dwarf-kind=split
.
split
stops being the default.split
is the default, we will not need it. -Zsymbol-mangling-version=v0
.
rust/exports.c
.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.
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,
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.
#7 introduces the machinery to support kernel parameters, but there are some things to do:
bool
and i32
— #7u8
, u16
, u32
, u64
and i16
— #82charp
/string
— #82 and #110invbool
was added a long time ago but was only ever used by 2 modules or so: we decided not to support it — #82bint
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
— #87hwparam_type
: probably another key in the dictionary, or use wrapper types.A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.