summaryrefslogtreecommitdiff
path: root/rust
AgeCommit message (Collapse)AuthorFilesLines
2023-02-20Merge tag 'rust-6.3' of https://github.com/Rust-for-Linux/linuxLinus Torvalds13-502/+806
Pull Rust updates from Miguel Ojeda: "More core additions, getting closer to a point where the first Rust modules can be upstreamed. The major ones being: - Sync: new types 'Arc', 'ArcBorrow' and 'UniqueArc'. - Types: new trait 'ForeignOwnable' and new type 'ScopeGuard'. There is also a substantial removal in terms of lines: - 'alloc' crate: remove the 'borrow' module (type 'Cow' and trait 'ToOwned')" * tag 'rust-6.3' of https://github.com/Rust-for-Linux/linux: rust: delete rust-project.json when running make clean rust: MAINTAINERS: Add the zulip link rust: types: implement `ForeignOwnable` for `Arc<T>` rust: types: implement `ForeignOwnable` for the unit type rust: types: implement `ForeignOwnable` for `Box<T>` rust: types: introduce `ForeignOwnable` rust: types: introduce `ScopeGuard` rust: prelude: prevent doc inline of external imports rust: sync: add support for dispatching on Arc and ArcBorrow. rust: sync: introduce `UniqueArc` rust: sync: allow type of `self` to be `ArcBorrow<T>` rust: sync: introduce `ArcBorrow` rust: sync: allow coercion from `Arc<T>` to `Arc<U>` rust: sync: allow type of `self` to be `Arc<T>` or variants rust: sync: add `Arc` for ref-counted allocations rust: compiler_builtins: make stubs non-global rust: alloc: remove the `borrow` module (`ToOwned`, `Cow`)
2023-02-07rust: types: implement `ForeignOwnable` for `Arc<T>`Wedson Almeida Filho1-1/+31
This allows us to hand ownership of Rust ref-counted objects to the C side of the kernel. Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Reviewed-by: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com> Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-02-01rust: types: implement `ForeignOwnable` for the unit typeWedson Almeida Filho1-0/+12
This allows us to use the unit type `()` when we have no object whose ownership must be managed but one implementing the `ForeignOwnable` trait is needed. Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-02-01rust: types: implement `ForeignOwnable` for `Box<T>`Wedson Almeida Filho1-0/+23
This allows us to hand ownership of Rust dynamically allocated objects to the C side of the kernel. Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Reviewed-by: Alice Ferrazzi <alice.ferrazzi@miraclelinux.com> Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-02-01rust: types: introduce `ForeignOwnable`Wedson Almeida Filho2-0/+55
It was originally called `PointerWrapper`. It is used to convert a Rust object to a pointer representation (void *) that can be stored on the C side, used, and eventually returned to Rust. Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-02-01rust: types: introduce `ScopeGuard`Wedson Almeida Filho1-1/+125
This allows us to run some code when the guard is dropped (e.g., implicitly when it goes out of scope). We can also prevent the guard from running by calling its `dismiss()` method. Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-01-16rust: prelude: prevent doc inline of external importsFinn Behrens1-1/+7
This shows exactly where the items are from, previously the items from macros, alloc and core were shown as a declaration from the kernel crate, this shows the correct path. Link: https://github.com/rust-lang/rust/issues/106713 Signed-off-by: Finn Behrens <fin@nyantec.com> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> [Reworded to add Link, fixed two typos and comment style] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-01-16rust: sync: add support for dispatching on Arc and ArcBorrow.Wedson Almeida Filho2-2/+19
Trait objects (`dyn T`) require trait `T` to be "object safe". One of the requirements for "object safety" is that the receiver have one of the allowed types. This commit adds `Arc<T>` and `ArcBorrow<'_, T>` to the list of allowed types. Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Acked-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-01-16rust: sync: introduce `UniqueArc`Wedson Almeida Filho2-3/+151
Since `Arc<T>` does not allow mutating `T` directly (i.e., without inner mutability), it is currently not possible to do some initialisation of `T` post construction but before being shared. `UniqueArc<T>` addresses this problem essentially being an `Arc<T>` that has a refcount of 1 and is therefore writable. Once initialisation is completed, it can be transitioned (without failure paths) into an `Arc<T>`. Suggested-by: Gary Guo <gary@garyguo.net> Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Acked-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-01-16rust: sync: allow type of `self` to be `ArcBorrow<T>`Wedson Almeida Filho1-0/+23
This allows associated functions whose `self` argument has `ArcBorrow<T>` as their type. This, in turn, allows callers to use the dot syntax to make calls. Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Acked-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-01-16rust: sync: introduce `ArcBorrow`Wedson Almeida Filho2-1/+98
This allows us to create references to a ref-counted allocation without double-indirection and that still allow us to increment the refcount to a new `Arc<T>`. Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-01-16rust: sync: allow coercion from `Arc<T>` to `Arc<U>`Wedson Almeida Filho2-1/+28
The coercion is only allowed if `U` is a compatible dynamically-sized type (DST). For example, if we have some type `X` that implements trait `Y`, then this allows `Arc<X>` to be coerced into `Arc<dyn Y>`. Suggested-by: Gary Guo <gary@garyguo.net> Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Acked-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-01-16rust: sync: allow type of `self` to be `Arc<T>` or variantsWedson Almeida Filho2-0/+29
This allows associated functions whose `self` argument has `Arc<T>` or variants as their type. This, in turn, allows callers to use the dot syntax to make calls. Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Acked-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-01-16rust: sync: add `Arc` for ref-counted allocationsWedson Almeida Filho6-0/+189
This is a basic implementation of `Arc` backed by C's `refcount_t`. It allows Rust code to idiomatically allocate memory that is ref-counted. Cc: Will Deacon <will@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Acked-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-01-16rust: compiler_builtins: make stubs non-globalGary Guo2-1/+18
Currently we define a number of stubs for compiler-builtin intrinsics that compiled libcore generates. The defined stubs are weak so they will not conflict with genuine implementation of these intrinsics, but their effect is global and will cause non-libcore code that accidently generate these intrinsics calls compile and bug on runtime. Instead of defining a stub that can affect all code, this patch uses objcopy's `--redefine-sym` flag to redirect these calls (from libcore only) to a prefixed version (e.g. redirect `__multi3` to `__rust_multi3`), so we can define panciking stubs that are only visible to libcore. This patch was previously discussed on GitHub [1]. This approach was also independently proposed by Nick Desaulniers in [2]. Link: https://github.com/Rust-for-Linux/linux/pull/779 [1] Link: https://lore.kernel.org/lkml/CAKwvOdkc0Qhwu=gfe1+H23TnAa6jnO6A3ZCO687dH6mSrATmDA@mail.gmail.com/ Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Wei Liu <wei.liu@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2023-01-16rust: alloc: remove the `borrow` module (`ToOwned`, `Cow`)Miguel Ojeda4-499/+6
The `Cow` type [1] requires that its generic parameter type implements the `ToOwned` trait [2], which provides a method to create owned data from borrowed data, usually by cloning. However, it is infallible, and thus in most cases it is not useful for the kernel. [3] Therefore, introduce `cfg(no_borrow)` to remove the `borrow` module (which contains `ToOwned` and `Cow`) from `alloc`. Link: https://doc.rust-lang.org/alloc/borrow/enum.Cow.html [1] Link: https://doc.rust-lang.org/alloc/borrow/trait.ToOwned.html [2] Link: https://lore.kernel.org/rust-for-linux/20221204103153.117675b1@GaryWorkstation/ [3] Cc: Gary Guo <gary@garyguo.net> Cc: Wedson Almeida Filho <wedsonaf@gmail.com> Cc: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Wei Liu <wei.liu@kernel.org> Reviewed-by: Finn Behrens <fin@nyantec.com>
2023-01-16rust: print: avoid evaluating arguments in `pr_*` macros in `unsafe` blocksMiguel Ojeda1-11/+18
At the moment it is possible to perform unsafe operations in the arguments of `pr_*` macros since they are evaluated inside an `unsafe` block: let x = &10u32 as *const u32; pr_info!("{}", *x); In other words, this is a soundness issue. Fix it so that it requires an explicit `unsafe` block. Reported-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reported-by: Domen Puncer Kugler <domen.puncerkugler@nccgroup.com> Link: https://github.com/Rust-for-Linux/linux/issues/479 Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
2022-12-04rust: types: add `Opaque` typeWedson Almeida Filho1-0/+25
Add the `Opaque` type, which is meant to be used with FFI objects that are never interpreted by Rust code, e.g.: struct Waiter { completion: Opaque<bindings::completion>, next: *mut Waiter, } It has the advantage that the objects don't have to be zero-initialised before calling their init functions, making the code performance closer to C. Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: types: add `Either` typeWedson Almeida Filho2-0/+13
Introduce the new `types` module of the `kernel` crate with `Either` as its first type. `Either<L, R>` is a sum type that always holds either a value of type `L` (`Left` variant) or `R` (`Right` variant). For instance: struct Executor { queue: Either<BoxedQueue, &'static Queue>, } Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Wei Liu <wei.liu@kernel.org> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: build_assert: add `build_{error,assert}!` macrosGary Guo3-0/+88
Add the `build_error!` and `build_assert!` macros which leverage the previously introduced `build_error` crate. Do so in a new module, called `build_assert`. The former fails the build if the code path calling it can possibly be executed. The latter asserts that a boolean expression is `true` at compile time. In particular, `build_assert!` can be used in some contexts where `static_assert!` cannot: fn f1<const N: usize>() { static_assert!(N > 1);` // Error. build_assert!(N > 1); // Build-time check. assert!(N > 1); // Run-time check. } #[inline] fn f2(n: usize) { static_assert!(n > 1); // Error. build_assert!(n > 1); // Build-time check. assert!(n > 1); // Run-time check. } Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Wei Liu <wei.liu@kernel.org> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: add `build_error` crateGary Guo3-5/+53
The `build_error` crate provides a function `build_error` which will panic at compile-time if executed in const context and, by default, will cause a build error if not executed at compile time and the optimizer does not optimise away the call. The `CONFIG_RUST_BUILD_ASSERT_ALLOW` kernel option allows to relax the default build failure and convert it to a runtime check. If the runtime check fails, `panic!` will be called. Its functionality will be exposed to users as a couple macros in the `kernel` crate in the following patch, thus some documentation here refers to them for simplicity. Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Wei Liu <wei.liu@kernel.org> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: static_assert: add `static_assert!` macroMiguel Ojeda3-0/+37
Add the `static_assert!` macro, which is a compile-time assert, similar to the C11 `_Static_assert` and C++11 `static_assert` declarations [1,2]. Do so in a new module, called `static_assert`. For instance: static_assert!(42 > 24); static_assert!(core::mem::size_of::<u8>() == 1); const X: &[u8] = b"bar"; static_assert!(X[1] == b'a'); const fn f(x: i32) -> i32 { x + 2 } static_assert!(f(40) == 42); Link: https://en.cppreference.com/w/c/language/_Static_assert [1] Link: https://en.cppreference.com/w/cpp/language/static_assert [2] Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: std_vendor: add `dbg!` macro based on `std`'s oneNiklas Mohrin3-1/+166
The Rust standard library has a really handy macro, `dbg!` [1,2]. It prints the source location (filename and line) along with the raw source code that is invoked with and the `Debug` representation of the given expression, e.g.: let a = 2; let b = dbg!(a * 2) + 1; // ^-- prints: [src/main.rs:2] a * 2 = 4 assert_eq!(b, 5); Port the macro over to the `kernel` crate inside a new module called `std_vendor`, using `pr_info!` instead of `eprintln!` and make the rules about committing uses of `dbg!` into version control more concrete (i.e. tailored for the kernel). Since the source code for the macro is taken from the standard library source (with only minor adjustments), the new file is licensed under `Apache 2.0 OR MIT`, just like the original [3,4]. Link: https://doc.rust-lang.org/std/macro.dbg.html [1] Link: https://github.com/rust-lang/rust/blob/master/library/std/src/macros.rs#L212 [2] Link: https://github.com/rust-lang/rust/blob/master/library/std/Cargo.toml [3] Link: https://github.com/rust-lang/rust/blob/master/COPYRIGHT [4] Signed-off-by: Niklas Mohrin <dev@niklasmohrin.de> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: add `fmt!` macroWedson Almeida Filho1-0/+6
Add the `fmt!` macro, which is a convenience alias for the Rust `core::format_args!` macro. For instance, it may be used to create a `CString`: CString::try_from_fmt(fmt!("{}{}", "abc", 42))? Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: add `CString` typeWedson Almeida Filho1-2/+89
Add the `CString` type, which is an owned string that is guaranteed to have exactly one `NUL` byte at the end, i.e. the owned equivalent to `CStr` introduced earlier. It is used for interoperability with kernel APIs that take C strings. In order to do so, implement the `RawFormatter::new()` constructor and the `RawFormatter::bytes_written()` method as well. Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: add `Formatter` typeWedson Almeida Filho1-0/+57
Add the `Formatter` type, which leverages `RawFormatter`, but fails if callers attempt to write more than will fit in the buffer. In order to so, implement the `RawFormatter::from_buffer()` constructor as well. Co-developed-by: Adam Bratschi-Kaye <ark.email@gmail.com> Signed-off-by: Adam Bratschi-Kaye <ark.email@gmail.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: add `c_str!` macroGary Guo1-0/+23
Add `c_str!`, which is a convenience macro that creates a new `CStr` from a string literal. It is designed to be similar to a `str` in usage, and it is usable in const contexts, for instance: const X: &CStr = c_str!("Example"); Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: add `CStr` unit testsMilan Landaverde1-0/+29
Add unit tests for `CStr::from_bytes_with_nul()` and `CStr::from_bytes_with_nul_unchecked()`. These serve as an example of the first unit tests for Rust code (i.e. different from documentation tests). Signed-off-by: Milan Landaverde <milan@mdaverde.com> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: implement several traits for `CStr`Gary Guo1-1/+123
Implement `Debug`, `Display`, `Deref` (into `BStr`), `AsRef<BStr>` and a set of `Index<...>` traits. This makes it `CStr` more convenient to use (and closer to `str`). Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Co-developed-by: Morgan Bartlett <mjmouse9999@gmail.com> Signed-off-by: Morgan Bartlett <mjmouse9999@gmail.com> Signed-off-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: add `CStr` typeGary Guo2-1/+170
Add the `CStr` type, which is a borrowed string that is guaranteed to have exactly one `NUL` byte, which is at the end. It is used for interoperability with kernel APIs that take C strings. Add it to the prelude too. Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Co-developed-by: Milan Landaverde <milan@mdaverde.com> Signed-off-by: Milan Landaverde <milan@mdaverde.com> Signed-off-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: add `b_str!` macroGary Guo1-0/+21
Add the `b_str!` macro, which creates a new `BStr` from a string literal. It is usable in const contexts, for instance: const X: &BStr = b_str!("Example"); Signed-off-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: str: add `BStr` typeGary Guo1-0/+5
Add the `BStr` type, which is a byte string without UTF-8 validity guarantee. It is simply an alias to `[u8]`, but has a more evident semantical meaning. Signed-off-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: alloc: add `Vec::try_with_capacity{,_in}()` constructorsMiguel Ojeda2-1/+89
Add `Vec::try_with_capacity()` and `Vec::try_with_capacity_in()` as the fallible versions of `Vec::with_capacity()` and `Vec::with_capacity_in()`, respectively. The implementations follow the originals and use the previously added `RawVec::try_with_capacity_in()`. In turn, `Vec::try_with_capacity()` will be used to implement the `CString` type (which wraps a `Vec<u8>`) in a later patch. Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: alloc: add `RawVec::try_with_capacity_in()` constructorMiguel Ojeda1-1/+33
Add the `RawVec::try_with_capacity_in()` constructor as the fallible version of `RawVec::with_capacity_in()`. The implementation follows the original. The infallible constructor is implemented in terms of the private `RawVec::allocate_in()` constructor, thus also add the private `RawVec::try_allocate_in()` constructor following the other. It will be used to implement `Vec::try_with_capacity{,_in}()` in the next patch. Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: prelude: add `error::code::*` constant itemsWedson Almeida Filho1-1/+1
It is convenient to have all the `Error` constant items (such as `EINVAL`) available as-is everywhere (i.e. for code using the kernel prelude such as kernel modules). Therefore, add all of them to the prelude. For instance, this allows to write `Err(EINVAL)` to create a kernel `Result`: fn f() -> Result<...> { ... Err(EINVAL) } Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: error: add `From` implementations for `Error`Wedson Almeida Filho2-1/+45
Add a set of `From` implementations for the `Error` kernel type. These implementations allow to easily convert from standard Rust error types to the usual kernel errors based on one of the `E*` integer codes. On top of that, the question mark Rust operator (`?`) implicitly performs a conversion on the error value using the `From` trait when propagating. Thus it is extra convenient to use. For instance, a kernel function that needs to convert a `i64` into a `i32` and to bubble up the error as a kernel error may write: fn f(x: i64) -> Result<...> { ... let y = i32::try_from(x)?; ... } which will transform the `TryFromIntError` into an `Err(EINVAL)`. Co-developed-by: Adam Bratschi-Kaye <ark.email@gmail.com> Signed-off-by: Adam Bratschi-Kaye <ark.email@gmail.com> Co-developed-by: Nándor István Krácser <bonifaido@gmail.com> Signed-off-by: Nándor István Krácser <bonifaido@gmail.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Reviewed-by: Finn Behrens <me@kloenk.dev> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: error: add codes from `errno-base.h`Viktor Garske1-0/+33
Only a few codes were added so far. With the `declare_err!` macro in place, add the remaining ones (which is most of them) from `include/uapi/asm-generic/errno-base.h`. Co-developed-by: Wedson Almeida Filho <wedsonaf@gmail.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Signed-off-by: Viktor Garske <viktor@v-gar.de> Reviewed-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: error: declare errors using macroFinn Behrens1-2/+10
Add a macro to declare errors, which simplifies the work needed to add each one, avoids repetition of the code and makes it easier to change the way they are declared. Signed-off-by: Finn Behrens <me@kloenk.dev> Reviewed-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: macros: take string literals in `module!`Gary Guo3-17/+29
Instead of taking binary string literals, take string ones instead, making it easier for users to define a module, i.e. instead of calling `module!` like: module! { ... name: b"rust_minimal", ... } now it is called as: module! { ... name: "rust_minimal", ... } Module names, aliases and license strings are restricted to ASCII only. However, the author and the description allows UTF-8. For simplicity (avoid parsing), escape sequences and raw string literals are not yet handled. Link: https://github.com/Rust-for-Linux/linux/issues/252 Link: https://lore.kernel.org/lkml/YukvvPOOu8uZl7+n@yadro.com/ Signed-off-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: macros: add `#[vtable]` proc macroGary Guo3-1/+148
This procedural macro attribute provides a simple way to declare a trait with a set of operations that later users can partially implement, providing compile-time `HAS_*` boolean associated constants that indicate whether a particular operation was overridden. This is useful as the Rust counterpart to structs like `file_operations` where some pointers may be `NULL`, indicating an operation is not provided. For instance: #[vtable] trait Operations { fn read(...) -> Result<usize> { Err(EINVAL) } fn write(...) -> Result<usize> { Err(EINVAL) } } #[vtable] impl Operations for S { fn read(...) -> Result<usize> { ... } } assert_eq!(<S as Operations>::HAS_READ, true); assert_eq!(<S as Operations>::HAS_WRITE, false); Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Sergio González Collado <sergio.collado@gmail.com> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-04rust: macros: add `concat_idents!` proc macroBjörn Roy Baron2-0/+67
This macro provides similar functionality to the unstable feature `concat_idents` without having to rely on it. For instance: let x_1 = 42; let x_2 = concat_idents!(x, _1); assert!(x_1 == x_2); It has different behavior with respect to macro hygiene. Unlike the unstable `concat_idents!` macro, it allows, for example, referring to local variables by taking the span of the second macro as span for the output identifier. Signed-off-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Reviewed-by: Finn Behrens <me@kloenk.dev> Reviewed-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-01rust: print: add `pr_cont!` macroMiguel Ojeda1-9/+63
This level is a bit different from the rest since it does not pass the module name to the `_printk()` call. Thus add a new parameter to the general `print_macro!` to handle it differently. Co-developed-by: Adam Bratschi-Kaye <ark.email@gmail.com> Signed-off-by: Adam Bratschi-Kaye <ark.email@gmail.com> Co-developed-by: Wedson Almeida Filho <wedsonaf@gmail.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Co-developed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Wei Liu <wei.liu@kernel.org> Reviewed-by: Sergio González Collado <sergio.collado@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-01rust: print: add more `pr_*!` levelsMiguel Ojeda2-1/+155
Currently, only `pr_info!` (for the minimal sample) and `pr_emerg!` (for the panic handler) are there. Add the other levels as new macros, i.e. `pr_alert!`, `pr_crit!`, `pr_err!`, `pr_warn!`, `pr_notice!` and `pr_debug!`. Co-developed-by: Adam Bratschi-Kaye <ark.email@gmail.com> Signed-off-by: Adam Bratschi-Kaye <ark.email@gmail.com> Co-developed-by: Wedson Almeida Filho <wedsonaf@gmail.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com> Co-developed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Wei Liu <wei.liu@kernel.org> Reviewed-by: Sergio Gonzalez Collado <sergio.collado@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-12-01rust: prelude: split re-exports into groupsMiguel Ojeda1-5/+9
Split the prelude re-exports into groups: first the ones coming from the `core` crate, then `alloc`, then our own crates and finally the ones from modules from `kernel` itself (i.e. `super`). We are doing this manually for the moment, but ideally, long-term, this could be automated via `rustfmt` with options such as `group_imports` and `imports_granularity` (both currently unstable). Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Wei Liu <wei.liu@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-09-28Kbuild: add Rust supportMiguel Ojeda3-0/+410
Having most of the new files in place, we now enable Rust support in the build system, including `Kconfig` entries related to Rust, the Rust configuration printer and a few other bits. Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Co-developed-by: Finn Behrens <me@kloenk.de> Signed-off-by: Finn Behrens <me@kloenk.de> Co-developed-by: Adam Bratschi-Kaye <ark.email@gmail.com> Signed-off-by: Adam Bratschi-Kaye <ark.email@gmail.com> Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com> Co-developed-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Co-developed-by: Sven Van Asbroeck <thesven73@gmail.com> Signed-off-by: Sven Van Asbroeck <thesven73@gmail.com> Co-developed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Gary Guo <gary@garyguo.net> Co-developed-by: Boris-Chengbiao Zhou <bobo1239@web.de> Signed-off-by: Boris-Chengbiao Zhou <bobo1239@web.de> Co-developed-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Co-developed-by: Douglas Su <d0u9.su@outlook.com> Signed-off-by: Douglas Su <d0u9.su@outlook.com> Co-developed-by: Dariusz Sosnowski <dsosnowski@dsosnowski.pl> Signed-off-by: Dariusz Sosnowski <dsosnowski@dsosnowski.pl> Co-developed-by: Antonio Terceiro <antonio.terceiro@linaro.org> Signed-off-by: Antonio Terceiro <antonio.terceiro@linaro.org> Co-developed-by: Daniel Xu <dxu@dxuuu.xyz> Signed-off-by: Daniel Xu <dxu@dxuuu.xyz> Co-developed-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Signed-off-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Co-developed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Signed-off-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-09-28rust: export generated symbolsMiguel Ojeda1-0/+21
All symbols are reexported reusing the `EXPORT_SYMBOL_GPL` macro from C. The lists of symbols are generated on the fly. There are three main sets of symbols to distinguish: - The ones from the `core` and `alloc` crates (from the Rust standard library). The code is licensed as Apache/MIT. - The ones from our abstractions in the `kernel` crate. - The helpers (already exported since they are not generated). We export everything as GPL. This ensures we do not mistakenly expose GPL kernel symbols/features as non-GPL, even indirectly. Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com> Co-developed-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Signed-off-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-09-28rust: add `kernel` crateWedson Almeida Filho6-0/+491
The `kernel` crate currently includes all the abstractions that wrap kernel features written in C. These abstractions call the C side of the kernel via the generated bindings with the `bindgen` tool. Modules developed in Rust should never call the bindings themselves. In the future, as the abstractions grow in number, we may need to split this crate into several, possibly following a similar subdivision in subsystems as the kernel itself and/or moving the code to the actual subsystems. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Co-developed-by: Geoffrey Thomas <geofft@ldpreload.com> Signed-off-by: Geoffrey Thomas <geofft@ldpreload.com> Co-developed-by: Finn Behrens <me@kloenk.de> Signed-off-by: Finn Behrens <me@kloenk.de> Co-developed-by: Adam Bratschi-Kaye <ark.email@gmail.com> Signed-off-by: Adam Bratschi-Kaye <ark.email@gmail.com> Co-developed-by: Sven Van Asbroeck <thesven73@gmail.com> Signed-off-by: Sven Van Asbroeck <thesven73@gmail.com> Co-developed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Gary Guo <gary@garyguo.net> Co-developed-by: Boris-Chengbiao Zhou <bobo1239@web.de> Signed-off-by: Boris-Chengbiao Zhou <bobo1239@web.de> Co-developed-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Co-developed-by: Fox Chen <foxhlchen@gmail.com> Signed-off-by: Fox Chen <foxhlchen@gmail.com> Co-developed-by: Viktor Garske <viktor@v-gar.de> Signed-off-by: Viktor Garske <viktor@v-gar.de> Co-developed-by: Dariusz Sosnowski <dsosnowski@dsosnowski.pl> Signed-off-by: Dariusz Sosnowski <dsosnowski@dsosnowski.pl> Co-developed-by: Léo Lanteri Thauvin <leseulartichaut@gmail.com> Signed-off-by: Léo Lanteri Thauvin <leseulartichaut@gmail.com> Co-developed-by: Niklas Mohrin <dev@niklasmohrin.de> Signed-off-by: Niklas Mohrin <dev@niklasmohrin.de> Co-developed-by: Milan Landaverde <milan@mdaverde.com> Signed-off-by: Milan Landaverde <milan@mdaverde.com> Co-developed-by: Morgan Bartlett <mjmouse9999@gmail.com> Signed-off-by: Morgan Bartlett <mjmouse9999@gmail.com> Co-developed-by: Maciej Falkowski <m.falkowski@samsung.com> Signed-off-by: Maciej Falkowski <m.falkowski@samsung.com> Co-developed-by: Nándor István Krácser <bonifaido@gmail.com> Signed-off-by: Nándor István Krácser <bonifaido@gmail.com> Co-developed-by: David Gow <davidgow@google.com> Signed-off-by: David Gow <davidgow@google.com> Co-developed-by: John Baublitz <john.m.baublitz@gmail.com> Signed-off-by: John Baublitz <john.m.baublitz@gmail.com> Co-developed-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Signed-off-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com> Co-developed-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-09-28rust: add `bindings` crateMiguel Ojeda2-0/+66
This crate contains the bindings to the C side of the kernel. Calling C (in general, FFI) is assumed to be unsafe in Rust and, in many cases, this is accurate. For instance, virtually all C functions that take a pointer are unsafe since, typically, it will be dereferenced at some point (and in most cases there is no way for the callee to check its validity beforehand). Since one of the goals of using Rust in the kernel is precisely to avoid unsafe code in "leaf" kernel modules (e.g. drivers), these bindings should not be used directly by them. Instead, these bindings need to be wrapped into safe abstractions. These abstractions provide a safe API that kernel modules can use. In this way, unsafe code in kernel modules is minimized. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Co-developed-by: Finn Behrens <me@kloenk.de> Signed-off-by: Finn Behrens <me@kloenk.de> Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com> Co-developed-by: Sven Van Asbroeck <thesven73@gmail.com> Signed-off-by: Sven Van Asbroeck <thesven73@gmail.com> Co-developed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Gary Guo <gary@garyguo.net> Co-developed-by: Maciej Falkowski <m.falkowski@samsung.com> Signed-off-by: Maciej Falkowski <m.falkowski@samsung.com> Co-developed-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Co-developed-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Signed-off-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-09-28rust: add `macros` crateMiguel Ojeda3-0/+405
This crate contains all the procedural macros ("proc macros") shared by all the kernel. Procedural macros allow to create syntax extensions. They run at compile-time and can consume as well as produce Rust syntax. For instance, the `module!` macro that is used by Rust modules is implemented here. It allows to easily declare the equivalent information to the `MODULE_*` macros in C modules, e.g.: module! { type: RustMinimal, name: b"rust_minimal", author: b"Rust for Linux Contributors", description: b"Rust minimal sample", license: b"GPL", } Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Co-developed-by: Finn Behrens <me@kloenk.de> Signed-off-by: Finn Behrens <me@kloenk.de> Co-developed-by: Adam Bratschi-Kaye <ark.email@gmail.com> Signed-off-by: Adam Bratschi-Kaye <ark.email@gmail.com> Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com> Co-developed-by: Sumera Priyadarsini <sylphrenadin@gmail.com> Signed-off-by: Sumera Priyadarsini <sylphrenadin@gmail.com> Co-developed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Gary Guo <gary@garyguo.net> Co-developed-by: Matthew Bakhtiari <dev@mtbk.me> Signed-off-by: Matthew Bakhtiari <dev@mtbk.me> Co-developed-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Signed-off-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2022-09-28rust: add `compiler_builtins` crateMiguel Ojeda1-0/+63
Rust provides `compiler_builtins` as a port of LLVM's `compiler-rt`. Since we do not need the vast majority of them, we avoid the dependency by providing our own crate. Reviewed-by: Kees Cook <keescook@chromium.org> Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com> Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com> Co-developed-by: Sven Van Asbroeck <thesven73@gmail.com> Signed-off-by: Sven Van Asbroeck <thesven73@gmail.com> Co-developed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Gary Guo <gary@garyguo.net> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>