01db99b2 | 19-Aug-2024 |
Benno Lossin <benno.lossin@proton.me> |
rust: kernel: add `drop_contents` to `BoxExt`
Sometimes (see [1]) it is necessary to drop the value inside of a `Box<T>`, but retain the allocation. For example to reuse the allocation in the future
rust: kernel: add `drop_contents` to `BoxExt`
Sometimes (see [1]) it is necessary to drop the value inside of a `Box<T>`, but retain the allocation. For example to reuse the allocation in the future.
Introduce a new function `drop_contents` that turns a `Box<T>` into `Box<MaybeUninit<T>>` by dropping the value.
Link: https://lore.kernel.org/rust-for-linux/20240418-b4-rbtree-v3-5-323e134390ce@google.com/ [1] Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240819112415.99810-1-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
0ff8f3f0 | 19-Aug-2024 |
Michael Vetter <jubalh@iodoru.org> |
rust: kernel: fix typos in code comments
Fix spelling mistakes in code comments.
Signed-off-by: Michael Vetter <jubalh@iodoru.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno
rust: kernel: fix typos in code comments
Fix spelling mistakes in code comments.
Signed-off-by: Michael Vetter <jubalh@iodoru.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20240819205731.2163-1-jubalh@iodoru.org [ Reworded slightly. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
fd764e74 | 15-Aug-2024 |
Andreas Hindborg <a.hindborg@samsung.com> |
rust: block: fix wrong usage of lockdep API
When allocating `struct gendisk`, `GenDiskBuilder` is using a dynamic lock class key without registering the key. This is an incorrect use of the API, whi
rust: block: fix wrong usage of lockdep API
When allocating `struct gendisk`, `GenDiskBuilder` is using a dynamic lock class key without registering the key. This is an incorrect use of the API, which causes a `WARN` trace.
Fix the issue by using a static lock class key, which is more appropriate for the situation anyway.
Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module") Reported-by: Behme Dirk (XC-CP/ESB5) <Dirk.Behme@de.bosch.com> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/x/topic/x/near/457090036 Signed-off-by: Andreas Hindborg <a.hindborg@samsung.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Link: https://lore.kernel.org/r/20240815074519.2684107-3-nmi@metaspace.dk [ Applied `rustfmt`, reworded slightly and made Zulip link a permalink. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
76501d19 | 14-Aug-2024 |
Miguel Ojeda <ojeda@kernel.org> |
rust: enable bindgen's `--enable-function-attribute-detection` flag
`bindgen` is able to detect certain function attributes and annotate functions correspondingly in its output for the Rust side, wh
rust: enable bindgen's `--enable-function-attribute-detection` flag
`bindgen` is able to detect certain function attributes and annotate functions correspondingly in its output for the Rust side, when the `--enable-function-attribute-detection` is passed.
In particular, it is currently able to use `__must_check` in C (`#[must_use]` in Rust), which give us a bunch of annotations that are nice to have to prevent possible issues in Rust abstractions, e.g.:
extern "C" { + #[must_use] pub fn kobject_add( kobj: *mut kobject, parent: *mut kobject, fmt: *const core::ffi::c_char, ... ) -> core::ffi::c_int; }
Apparently, there are edge cases where this can make generation very slow, which is why it is behind a flag [1], but it does not seem to affect us in any major way at the moment.
Thus enable it.
Link: https://github.com/rust-lang/rust-bindgen/issues/1465 [1] Link: https://lore.kernel.org/rust-for-linux/CANiq72=u5Nrz_NW3U3_VqywJkD8pECA07q2pFDd1wjtXOWdkAQ@mail.gmail.com/ Reviewed-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20240814163722.1550064-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
1d158803 | 09-Aug-2024 |
Alice Ryhl <aliceryhl@google.com> |
rust: sort blk includes in bindings_helper.h
The headers in this file are sorted alphabetically, which makes it easy to quickly resolve conflicts by selecting all of the headers and invoking :'<,'>s
rust: sort blk includes in bindings_helper.h
The headers in this file are sorted alphabetically, which makes it easy to quickly resolve conflicts by selecting all of the headers and invoking :'<,'>sort to sort them. To keep this technique to resolve conflicts working, also apply sorting to symbols that are not letters.
This file is very prone to merge conflicts, so I think keeping conflict resolution really easy is more important than not messing with git blame history.
These includes were originally introduced in commit 3253aba3408a ("rust: block: introduce `kernel::block::mq` module").
Signed-off-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20240809132835.274603-1-aliceryhl@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
e26fa546 | 17-Aug-2024 |
Gary Guo <gary@garyguo.net> |
rust: kbuild: auto generate helper exports
This removes the need to explicitly export all symbols.
Generate helper exports similarly to what's currently done for Rust crates. These helpers are excl
rust: kbuild: auto generate helper exports
This removes the need to explicitly export all symbols.
Generate helper exports similarly to what's currently done for Rust crates. These helpers are exclusively called from within Rust code and therefore can be treated similar as other Rust symbols.
Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Link: https://lore.kernel.org/r/20240817165302.3852499-1-gary@garyguo.net [ Fixed dependency path, reworded slightly, edited comment a bit and rebased on top of the changes made when applying Andreas' patch (e.g. no `README.md` anymore, so moved the edits). - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
c4d7f546 | 25-Jul-2024 |
Miguel Ojeda <ojeda@kernel.org> |
objtool/kbuild/rust: enable objtool for Rust
Now that we should be `objtool`-warning free, enable `objtool` for Rust too.
Before this patch series, we were already getting warnings under e.g. IBT b
objtool/kbuild/rust: enable objtool for Rust
Now that we should be `objtool`-warning free, enable `objtool` for Rust too.
Before this patch series, we were already getting warnings under e.g. IBT builds, since those would see Rust code via `vmlinux.o`.
Tested-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240725183325.122827-7-ojeda@kernel.org [ Solved trivial conflict. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
289088d5 | 25-Jul-2024 |
Miguel Ojeda <ojeda@kernel.org> |
rust: module: add static pointer to `{init,cleanup}_module()`
Add the equivalent of the `___ADDRESSABLE()` annotation in the `module_{init,exit}` macros to the Rust `module!` macro.
Without this, `
rust: module: add static pointer to `{init,cleanup}_module()`
Add the equivalent of the `___ADDRESSABLE()` annotation in the `module_{init,exit}` macros to the Rust `module!` macro.
Without this, `objtool` would complain if enabled for Rust (under IBT builds), e.g.:
samples/rust/rust_print.o: warning: objtool: cleanup_module(): not an indirect call target samples/rust/rust_print.o: warning: objtool: init_module(): not an indirect call target
Tested-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240725183325.122827-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
87634653 | 15-Aug-2024 |
Andreas Hindborg <a.hindborg@samsung.com> |
rust: kbuild: split up helpers.c
This patch splits up the rust helpers C file. When rebasing patch sets on upstream linux, merge conflicts in helpers.c is common and time consuming [1]. Thus, split
rust: kbuild: split up helpers.c
This patch splits up the rust helpers C file. When rebasing patch sets on upstream linux, merge conflicts in helpers.c is common and time consuming [1]. Thus, split the file so that each kernel component can live in a separate file.
This patch lists helper files explicitly and thus conflicts in the file list is still likely. However, they should be more simple to resolve than the conflicts usually seen in helpers.c.
[ Removed `README.md` and undeleted the original comment since now, in v3 of the series, we have a `helpers.c` again; which also allows us to keep the "Sorted alphabetically" line and makes the diff easier.
In addition, updated the Documentation/ mentions of the file, reworded title and removed blank lines at the end of `page.c`. - Miguel ]
Link: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/Splitting.20up.20helpers.2Ec/near/426694012 [1] Signed-off-by: Andreas Hindborg <a.hindborg@samsung.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Dirk Behme <dirk.behme@de.bosch.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20240815103016.2771842-1-nmi@metaspace.dk Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
7bc18673 | 30-Jul-2024 |
Miguel Ojeda <ojeda@kernel.org> |
rust: error: allow `useless_conversion` for 32-bit builds
For the new Rust support for 32-bit arm [1], Clippy warns:
error: useless conversion to the same type: `i32` --> rust/kernel/err
rust: error: allow `useless_conversion` for 32-bit builds
For the new Rust support for 32-bit arm [1], Clippy warns:
error: useless conversion to the same type: `i32` --> rust/kernel/error.rs:139:36 | 139 | unsafe { bindings::ERR_PTR(self.0.into()) as *mut _ } | ^^^^^^^^^^^^^ help: consider removing `.into()`: `self.0` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#useless_conversion = note: `-D clippy::useless-conversion` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::useless_conversion)]`
The `self.0.into()` converts an `c_int` into `ERR_PTR`'s parameter which is a `c_long`. Thus, both types are `i32` in 32-bit. Therefore, allow it for those architectures.
Link: https://lore.kernel.org/rust-for-linux/2dbd1491-149d-443c-9802-75786a6a3b73@gmail.com/ [1] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com> Link: https://lore.kernel.org/r/20240730155702.1110144-1-ojeda@kernel.org [ Fixed typo in tag. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
7adcdd57 | 30-Jul-2024 |
Benno Lossin <benno.lossin@proton.me> |
rust: types: improve `ForeignOwnable` documentation
There are no guarantees for the pointer returned by `into_foreign`. This is simply because there is no safety documentation stating any guarantees
rust: types: improve `ForeignOwnable` documentation
There are no guarantees for the pointer returned by `into_foreign`. This is simply because there is no safety documentation stating any guarantees. Therefore dereferencing and all other operations for that pointer are not allowed in a general context (i.e. when the concrete type implementing the trait is not known). This might be confusing, therefore add normal documentation to state that there are no guarantees given for the pointer.
Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240730182251.1466684-1-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
6c2d0ad5 | 30-Jul-2024 |
Alice Ryhl <aliceryhl@google.com> |
rust: implement ForeignOwnable for Pin<Box<T>>
We already implement ForeignOwnable for Box<T>, but it may be useful to store pinned data in a ForeignOwnable container. This patch makes that possible
rust: implement ForeignOwnable for Pin<Box<T>>
We already implement ForeignOwnable for Box<T>, but it may be useful to store pinned data in a ForeignOwnable container. This patch makes that possible.
This will be used together with upcoming miscdev abstractions, which Binder will use when binderfs is disabled.
Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20240730-foreign-ownable-pin-box-v1-1-b1d70cdae541@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
02dfd63a | 06-Aug-2024 |
Miguel Ojeda <ojeda@kernel.org> |
rust: add intrinsics to fix `-Os` builds
Alice reported [1] that an arm64 build failed with:
ld.lld: error: undefined symbol: __extendsfdf2 >>> referenced by core.a6f5fc5794e7b7b3-cgu.0
rust: add intrinsics to fix `-Os` builds
Alice reported [1] that an arm64 build failed with:
ld.lld: error: undefined symbol: __extendsfdf2 >>> referenced by core.a6f5fc5794e7b7b3-cgu.0 >>> rust/core.o:(<f32>::midpoint) in archive vmlinux.a >>> referenced by core.a6f5fc5794e7b7b3-cgu.0 >>> rust/core.o:(<f32>::midpoint) in archive vmlinux.a
ld.lld: error: undefined symbol: __truncdfsf2 >>> referenced by core.a6f5fc5794e7b7b3-cgu.0 >>> rust/core.o:(<f32>::midpoint) in archive vmlinux.a
Rust 1.80.0 or later together with `CONFIG_CC_OPTIMIZE_FOR_SIZE=y` is what triggers it.
In addition, x86_64 builds also fail the same way.
Similarly, compiling with Rust 1.82.0 (currently in nightly) makes another one appear, possibly due to the LLVM 19 upgrade there:
ld.lld: error: undefined symbol: __eqdf2 >>> referenced by core.20495ea57a9f069d-cgu.0 >>> rust/core.o:(<f64>::next_up) in archive vmlinux.a >>> referenced by core.20495ea57a9f069d-cgu.0 >>> rust/core.o:(<f64>::next_down) in archive vmlinux.a
Gary adds [1]:
> Usually the fix on rustc side is to mark those functions as `#[inline]` > > All of {midpoint,next_up,next_down} are indeed unstable functions not > marked as inline...
Fix all those by adding those intrinsics to our usual workaround.
[ Trevor quickly submitted a fix to upstream Rust [2] that has already been merged, to be released in Rust 1.82.0 (2024-10-17). - Miguel ]
Cc: Gary Guo <gary@garyguo.net> Reported-by: Alice Ryhl <aliceryhl@google.com> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/x/topic/x/near/455637364 [1] Reviewed-by: Trevor Gross <tmgross@umich.edu> Tested-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://github.com/rust-lang/rust/pull/128749 [2] Link: https://lore.kernel.org/r/20240806150619.192882-1-ojeda@kernel.org [ Shortened Zulip link. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
869b5016 | 31-Jul-2024 |
Zehui Xu <zehuixu@whu.edu.cn> |
kbuild: rust: skip -fmin-function-alignment in bindgen flags
GCC 14 recently added -fmin-function-alignment option and the root Makefile uses it to replace -falign-functions when available. However,
kbuild: rust: skip -fmin-function-alignment in bindgen flags
GCC 14 recently added -fmin-function-alignment option and the root Makefile uses it to replace -falign-functions when available. However, this flag can cause issues when passed to the Rust Makefile and affect the bindgen process. Bindgen relies on libclang to parse C code, and currently does not support the -fmin-function-alignment flag, leading to compilation failures when GCC 14 is used.
This patch addresses the issue by adding -fmin-function-alignment to the bindgen_skip_c_flags in rust/Makefile. This prevents the flag from causing compilation issues.
[ Matthew and Gary confirm function alignment should not change the ABI in a way that bindgen would care about, thus we did not need the extra logic for bindgen from v2. - Miguel ]
Link: https://lore.kernel.org/linux-kbuild/20240222133500.16991-1-petr.pavlu@suse.com/ Signed-off-by: Zehui Xu <zehuixu@whu.edu.cn> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Neal Gompa <neal@gompa.dev> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240731134346.10630-1-zehuixu@whu.edu.cn [ Reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
fe992163 | 24-Jul-2024 |
Sarthak Singh <sarthak.singh99@gmail.com> |
rust: Support latest version of `rust-analyzer`
Sets the `sysroot` field in rust-project.json which is now needed in newer versions of rust-analyzer instead of the `sysroot_src` field.
Till [1] `ru
rust: Support latest version of `rust-analyzer`
Sets the `sysroot` field in rust-project.json which is now needed in newer versions of rust-analyzer instead of the `sysroot_src` field.
Till [1] `rust-analyzer` used to guess the `sysroot` based on the `sysroot_src` at [2]. Now `sysroot` is a required parameter for a `rust-project.json` file. It is required because `rust-analyzer` need it to find the proc-macro server [3].
In the current version of `rust-analyzer` the `sysroot_src` is only used to include the inbuilt library crates (std, core, alloc, etc) [4]. Since we already specify the core library to be included in the `rust-project.json` we don't need to define the `sysroot_src`.
Code editors like VS Code try to use the latest version of rust-analyzer (which is updated every week) instead of the version of rust-analyzer that comes with the rustup toolchain (which is updated every six weeks along with the rust version).
Without this change `rust-analyzer` is breaking for anyone using VS Code. As they are getting the latest version of `rust-analyzer` with the changes made in [1].
`rust-analyzer` will also start breaking for other developers as they update their rust version (assuming that also updates the rust-analyzer version on their system).
This patch should work with every setup as there is no more guess work being done by `rust-analyzer`.
[ Lukas, who leads the rust-analyzer team, says:
`sysroot_src` is required now if you want to have the sysroot source libraries be loaded. I think we used to infer it as `{sysroot}/lib/rustlib/src/rust/library` before when only the `sysroot` field was given but that was since changed to make it possible in having a sysroot without the standard library sources (that is only have the binaries available). So if you want the library sources to be loaded by rust-analyzer you will have to set that field as well now.
- Miguel ]
Link: https://github.com/rust-lang/rust-analyzer/pull/17287 [1] Link: https://github.com/rust-lang/rust-analyzer/blob/f372a8a1176ff8dd5f45ab2ddd45f3530db0374f/crates/project-model/src/workspace.rs#L367-L374 [2] Link: https://github.com/rust-lang/rust-analyzer/blob/eeb192b79aeac47b40add66347022af17a74fbaf/crates/project-model/src/sysroot.rs#L180-L192 [3] Link: https://github.com/search?q=repo%3AVeykril%2Frust-analyzer%20src_root()&type=code [4] Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Signed-off-by: Sarthak Singh <sarthak.singh99@gmail.com> Link: https://rust-for-linux.zulipchat.com/#narrow/stream/291565-Help/topic/How.20to.20rust-analyzer.20correctly.20working Link: https://lore.kernel.org/r/20240724172713.899399-1-sarthak.singh99@gmail.com [ Formatted comment, fixed typo and removed spurious empty line. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
910bfc26 | 27-Jul-2024 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge tag 'rust-6.11' of https://github.com/Rust-for-Linux/linux
Pull Rust updates from Miguel Ojeda: "The highlight is the establishment of a minimum version for the Rust toolchain, including 'r
Merge tag 'rust-6.11' of https://github.com/Rust-for-Linux/linux
Pull Rust updates from Miguel Ojeda: "The highlight is the establishment of a minimum version for the Rust toolchain, including 'rustc' (and bundled tools) and 'bindgen'.
The initial minimum will be the pinned version we currently have, i.e. we are just widening the allowed versions. That covers three stable Rust releases: 1.78.0, 1.79.0, 1.80.0 (getting released tomorrow), plus beta, plus nightly.
This should already be enough for kernel developers in distributions that provide recent Rust compiler versions routinely, such as Arch Linux, Debian Unstable (outside the freeze period), Fedora Linux, Gentoo Linux (especially the testing channel), Nix (unstable) and openSUSE Slowroll and Tumbleweed.
In addition, the kernel is now being built-tested by Rust's pre-merge CI. That is, every change that is attempting to land into the Rust compiler is tested against the kernel, and it is merged only if it passes. Similarly, the bindgen tool has agreed to build the kernel in their CI too.
Thus, with the pre-merge CI in place, both projects hope to avoid unintentional changes to Rust that break the kernel. This means that, in general, apart from intentional changes on their side (that we will need to workaround conditionally on our side), the upcoming Rust compiler versions should generally work.
In addition, the Rust project has proposed getting the kernel into stable Rust (at least solving the main blockers) as one of its three flagship goals for 2024H2 [1].
I would like to thank Niko, Sid, Emilio et al. for their help promoting the collaboration between Rust and the kernel.
Toolchain and infrastructure:
- Support several Rust toolchain versions.
- Support several bindgen versions.
- Remove 'cargo' requirement and simplify 'rusttest', thanks to 'alloc' having been dropped last cycle.
- Provide proper error reporting for the 'rust-analyzer' target.
'kernel' crate:
- Add 'uaccess' module with a safe userspace pointers abstraction.
- Add 'page' module with a 'struct page' abstraction.
- Support more complex generics in workqueue's 'impl_has_work!' macro.
'macros' crate:
- Add 'firmware' field support to the 'module!' macro.
- Improve 'module!' macro documentation.
Documentation:
- Provide instructions on what packages should be installed to build the kernel in some popular Linux distributions.
- Introduce the new kernel.org LLVM+Rust toolchains.
- Explain '#[no_std]'.
And a few other small bits"
Link: https://rust-lang.github.io/rust-project-goals/2024h2/index.html#flagship-goals [1]
* tag 'rust-6.11' of https://github.com/Rust-for-Linux/linux: (26 commits) docs: rust: quick-start: add section on Linux distributions rust: warn about `bindgen` versions 0.66.0 and 0.66.1 rust: start supporting several `bindgen` versions rust: work around `bindgen` 0.69.0 issue rust: avoid assuming a particular `bindgen` build rust: start supporting several compiler versions rust: simplify Clippy warning flags set rust: relax most deny-level lints to warnings rust: allow `dead_code` for never constructed bindings rust: init: simplify from `map_err` to `inspect_err` rust: macros: indent list item in `paste!`'s docs rust: add abstraction for `struct page` rust: uaccess: add typed accessors for userspace pointers uaccess: always export _copy_[from|to]_user with CONFIG_RUST rust: uaccess: add userspace pointers kbuild: rust-analyzer: improve comment documentation kbuild: rust-analyzer: better error handling docs: rust: no_std is used rust: alloc: add __GFP_HIGHMEM flag rust: alloc: fix typo in docs for GFP_NOWAIT ...
show more ...
|