aboutsummaryrefslogtreecommitdiff
path: root/rust/kernel/print.rs
AgeCommit message (Collapse)AuthorFilesLines
2023-12-21rust: support `srctree`-relative linksMiguel Ojeda1-4/+4
Some of our links use relative paths in order to point to files in the source tree, e.g.: //! C header: [`include/linux/printk.h`](../../../../include/linux/printk.h) /// [`struct mutex`]: ../../../../include/linux/mutex.h These are problematic because they are hard to maintain and do not support `O=` builds. Instead, provide support for `srctree`-relative links, e.g.: //! C header: [`include/linux/printk.h`](srctree/include/linux/printk.h) /// [`struct mutex`]: srctree/include/linux/mutex.h The links are fixed after `rustdoc` generation to be based on the absolute path to the source tree. Essentially, this is the automatic version of Tomonori's fix [1], suggested by Gary [2]. Suggested-by: Gary Guo <[email protected]> Reported-by: FUJITA Tomonori <[email protected]> Closes: https://lore.kernel.org/r/[email protected] [1] Fixes: 48fadf440075 ("docs: Move rustdoc output, cross-reference it") Link: https://lore.kernel.org/rust-for-linux/20231026154525.6d14b495@eugeo/ [2] Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Benno Lossin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2023-10-15rust: print: use explicit link in documentationMiguel Ojeda1-0/+1
The future `rustdoc` in the Rust 1.73.0 upgrade requires an explicit link for `pr_info!`: error: unresolved link to `pr_info` --> rust/kernel/print.rs:395:63 | 395 | /// Use only when continuing a previous `pr_*!` macro (e.g. [`pr_info!`]). | ^^^^^^^^ no item named `pr_info` in scope | = note: `macro_rules` named `pr_info` exists in this crate, but it is not in scope at this link's location = note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings` Thus do so to avoid a broken link while upgrading. Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Vincenzo Palazzo <[email protected]> Reviewed-by: Finn Behrens <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2023-04-06rust: kernel: Mark rust_fmt_argument as extern "C"David Gow1-1/+5
The rust_fmt_argument function is called from printk() to handle the %pA format specifier. Since it's called from C, we should mark it extern "C" to make sure it's ABI compatible. Cc: [email protected] Fixes: 247b365dc8dc ("rust: add `kernel` crate") Signed-off-by: David Gow <[email protected]> Reviewed-by: Gary Guo <[email protected]> Reviewed-by: Björn Roy Baron <[email protected]> Reviewed-by: Vincenzo Palazzo <[email protected]> [Applied `rustfmt`] Signed-off-by: Miguel Ojeda <[email protected]>
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 <[email protected]> Reported-by: Domen Puncer Kugler <[email protected]> Link: https://github.com/Rust-for-Linux/linux/issues/479 Signed-off-by: Miguel Ojeda <[email protected]> Reviewed-by: Boqun Feng <[email protected]> Reviewed-by: Gary Guo <[email protected]> Reviewed-by: Björn Roy Baron <[email protected]> Reviewed-by: Vincenzo Palazzo <[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 Ojeda1-0/+154
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-09-28rust: add `kernel` crateWedson Almeida Filho1-0/+198
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]>