aboutsummaryrefslogtreecommitdiff
path: root/rust
AgeCommit message (Collapse)AuthorFilesLines
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 <[email protected]> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Reviewed-by: Gary Guo <[email protected]> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Signed-off-by: Adam Bratschi-Kaye <[email protected]> Co-developed-by: Nándor István Krácser <[email protected]> Signed-off-by: Nándor István Krácser <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Reviewed-by: Finn Behrens <[email protected]> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Viktor Garske <[email protected]> Reviewed-by: Gary Guo <[email protected]> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Reviewed-by: Gary Guo <[email protected]> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <[email protected]>
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/[email protected]/ Signed-off-by: Gary Guo <[email protected]> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Reviewed-by: Sergio González Collado <[email protected]> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Reviewed-by: Finn Behrens <[email protected]> Reviewed-by: Gary Guo <[email protected]> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Signed-off-by: Adam Bratschi-Kaye <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Reviewed-by: Wei Liu <[email protected]> Reviewed-by: Sergio González Collado <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Signed-off-by: Adam Bratschi-Kaye <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Reviewed-by: Boqun Feng <[email protected]> Reviewed-by: Wei Liu <[email protected]> Reviewed-by: Sergio Gonzalez Collado <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Reviewed-by: Wei Liu <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Finn Behrens <[email protected]> Signed-off-by: Finn Behrens <[email protected]> Co-developed-by: Adam Bratschi-Kaye <[email protected]> Signed-off-by: Adam Bratschi-Kaye <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Michael Ellerman <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Co-developed-by: Sven Van Asbroeck <[email protected]> Signed-off-by: Sven Van Asbroeck <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Boris-Chengbiao Zhou <[email protected]> Signed-off-by: Boris-Chengbiao Zhou <[email protected]> Co-developed-by: Boqun Feng <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Co-developed-by: Douglas Su <[email protected]> Signed-off-by: Douglas Su <[email protected]> Co-developed-by: Dariusz Sosnowski <[email protected]> Signed-off-by: Dariusz Sosnowski <[email protected]> Co-developed-by: Antonio Terceiro <[email protected]> Signed-off-by: Antonio Terceiro <[email protected]> Co-developed-by: Daniel Xu <[email protected]> Signed-off-by: Daniel Xu <[email protected]> Co-developed-by: Björn Roy Baron <[email protected]> Signed-off-by: Björn Roy Baron <[email protected]> Co-developed-by: Martin Rodriguez Reboredo <[email protected]> Signed-off-by: Martin Rodriguez Reboredo <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Björn Roy Baron <[email protected]> Signed-off-by: Björn Roy Baron <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Geoffrey Thomas <[email protected]> Signed-off-by: Geoffrey Thomas <[email protected]> Co-developed-by: Finn Behrens <[email protected]> Signed-off-by: Finn Behrens <[email protected]> Co-developed-by: Adam Bratschi-Kaye <[email protected]> Signed-off-by: Adam Bratschi-Kaye <[email protected]> Co-developed-by: Sven Van Asbroeck <[email protected]> Signed-off-by: Sven Van Asbroeck <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Boris-Chengbiao Zhou <[email protected]> Signed-off-by: Boris-Chengbiao Zhou <[email protected]> Co-developed-by: Boqun Feng <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Co-developed-by: Fox Chen <[email protected]> Signed-off-by: Fox Chen <[email protected]> Co-developed-by: Viktor Garske <[email protected]> Signed-off-by: Viktor Garske <[email protected]> Co-developed-by: Dariusz Sosnowski <[email protected]> Signed-off-by: Dariusz Sosnowski <[email protected]> Co-developed-by: Léo Lanteri Thauvin <[email protected]> Signed-off-by: Léo Lanteri Thauvin <[email protected]> Co-developed-by: Niklas Mohrin <[email protected]> Signed-off-by: Niklas Mohrin <[email protected]> Co-developed-by: Milan Landaverde <[email protected]> Signed-off-by: Milan Landaverde <[email protected]> Co-developed-by: Morgan Bartlett <[email protected]> Signed-off-by: Morgan Bartlett <[email protected]> Co-developed-by: Maciej Falkowski <[email protected]> Signed-off-by: Maciej Falkowski <[email protected]> Co-developed-by: Nándor István Krácser <[email protected]> Signed-off-by: Nándor István Krácser <[email protected]> Co-developed-by: David Gow <[email protected]> Signed-off-by: David Gow <[email protected]> Co-developed-by: John Baublitz <[email protected]> Signed-off-by: John Baublitz <[email protected]> Co-developed-by: Björn Roy Baron <[email protected]> Signed-off-by: Björn Roy Baron <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Miguel Ojeda <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Finn Behrens <[email protected]> Signed-off-by: Finn Behrens <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Sven Van Asbroeck <[email protected]> Signed-off-by: Sven Van Asbroeck <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Maciej Falkowski <[email protected]> Signed-off-by: Maciej Falkowski <[email protected]> Co-developed-by: Jiapeng Chong <[email protected]> Signed-off-by: Jiapeng Chong <[email protected]> Co-developed-by: Björn Roy Baron <[email protected]> Signed-off-by: Björn Roy Baron <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Finn Behrens <[email protected]> Signed-off-by: Finn Behrens <[email protected]> Co-developed-by: Adam Bratschi-Kaye <[email protected]> Signed-off-by: Adam Bratschi-Kaye <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Sumera Priyadarsini <[email protected]> Signed-off-by: Sumera Priyadarsini <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Matthew Bakhtiari <[email protected]> Signed-off-by: Matthew Bakhtiari <[email protected]> Co-developed-by: Björn Roy Baron <[email protected]> Signed-off-by: Björn Roy Baron <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Sven Van Asbroeck <[email protected]> Signed-off-by: Sven Van Asbroeck <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28rust: adapt `alloc` crate to the kernelMiguel Ojeda14-1/+100
This customizes the subset of the Rust standard library `alloc` that was just imported as-is, mainly by: - Adding SPDX license identifiers. - Skipping modules (e.g. `rc` and `sync`) via new `cfg`s. - Adding fallible (`try_*`) versions of existing infallible methods (i.e. returning a `Result` instead of panicking). Since the standard library requires stable/unstable attributes, these additions are annotated with: #[stable(feature = "kernel", since = "1.0.0")] Using "kernel" as the feature allows to have the additions clearly marked. The "1.0.0" version is just a placeholder. (At the moment, only one is needed, but in the future more fallible methods will be added). Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Matthew Bakhtiari <[email protected]> Signed-off-by: Matthew Bakhtiari <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28rust: import upstream `alloc` crateMiguel Ojeda13-0/+9037
This is a subset of the Rust standard library `alloc` crate, version 1.62.0, licensed under "Apache-2.0 OR MIT", from: https://github.com/rust-lang/rust/tree/1.62.0/library/alloc/src The files are copied as-is, with no modifications whatsoever (not even adding the SPDX identifiers). For copyright details, please see: https://github.com/rust-lang/rust/blob/1.62.0/COPYRIGHT The next patch modifies these files as needed for use within the kernel. This patch split allows reviewers to double-check the import and to clearly see the differences introduced. Vendoring `alloc`, at least for the moment, allows us to have fallible allocations support (i.e. the `try_*` versions of methods which return a `Result` instead of panicking) early on. It also gives a bit more freedom to experiment with new interfaces and to iterate quickly. Eventually, the goal is to have everything the kernel needs in upstream `alloc` and drop it from the kernel tree. For a summary of work on `alloc` happening upstream, please see: https://github.com/Rust-for-Linux/linux/issues/408 The following script may be used to verify the contents: for path in $(cd rust/alloc/ && find . -type f -name '*.rs'); do curl --silent --show-error --location \ https://github.com/rust-lang/rust/raw/1.62.0/library/alloc/src/$path \ | diff --unified rust/alloc/$path - && echo $path: OK done Reviewed-by: Kees Cook <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>
2022-09-28rust: add C helpersMiguel Ojeda1-0/+51
Introduces the source file that will contain forwarders to C macros and inlined functions. Initially this only contains a single helper, but will gain more as more functionality is added to the `kernel` crate in the future. Reviewed-by: Greg Kroah-Hartman <[email protected]> Co-developed-by: Alex Gaynor <[email protected]> Signed-off-by: Alex Gaynor <[email protected]> Co-developed-by: Geoffrey Thomas <[email protected]> Signed-off-by: Geoffrey Thomas <[email protected]> Co-developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Sven Van Asbroeck <[email protected]> Signed-off-by: Sven Van Asbroeck <[email protected]> Co-developed-by: Gary Guo <[email protected]> Signed-off-by: Gary Guo <[email protected]> Co-developed-by: Boqun Feng <[email protected]> Signed-off-by: Boqun Feng <[email protected]> Co-developed-by: Maciej Falkowski <[email protected]> Signed-off-by: Maciej Falkowski <[email protected]> Co-developed-by: Wei Liu <[email protected]> Signed-off-by: Wei Liu <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]>