linux-toradex.git/rust/kernel/print.rs, branch v6.12-rc4

rust: kernel: use docs.kernel.org links in code documentation

2024-08-25T12:44:34+00:00

Use links to docs.kernel.org instead of www.kernel.org/doc/html/latest
in the code documentation. The links are shorter and cleaner.

Link: https://github.com/Rust-for-Linux/linux/issues/1101
Signed-off-by: Michael Vetter 
[ Reworded slightly. - Miguel ]
Signed-off-by: Miguel Ojeda

rust: kernel: remove redundant imports

2024-05-05T17:22:25+00:00

Rust's `unused_imports` lint covers both unused and redundant imports.
In the upcoming 1.78.0, the lint detects more cases of redundant imports
[1], e.g.:

    error: the item `bindings` is imported redundantly
      --> rust/kernel/print.rs:38:9
       |
    38 |     use crate::bindings;
       |         ^^^^^^^^^^^^^^^ the item `bindings` is already defined by prelude

Most cases are `use crate::bindings`, plus a few other items like `Box`.
Thus clean them up.

Note that, in the `bindings` case, the message "defined by prelude"
above means the extern prelude, i.e. the `--extern` flags we pass.

Link: https://github.com/rust-lang/rust/pull/117772 [1]
Reviewed-by: Alice Ryhl 
Link: https://lore.kernel.org/r/20240401212303.537355-3-ojeda@kernel.org
Signed-off-by: Miguel Ojeda

rust: support `srctree`-relative links

2023-12-21T19:54:17+00:00

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 
Reported-by: FUJITA Tomonori 
Closes: https://lore.kernel.org/r/20231026.204058.2167744626131849993.fujita.tomonori@gmail.com [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 
Reviewed-by: Benno Lossin 
Link: https://lore.kernel.org/r/20231215235428.243211-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda

rust: print: use explicit link in documentation

2023-10-15T19:25:08+00:00

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 
Reviewed-by: Vincenzo Palazzo 
Reviewed-by: Finn Behrens 
Reviewed-by: Martin Rodriguez Reboredo 
Link: https://lore.kernel.org/r/20231005210556.466856-3-ojeda@kernel.org
Signed-off-by: Miguel Ojeda

rust: kernel: Mark rust_fmt_argument as extern "C"

2023-04-06T21:11:04+00:00

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: stable@vger.kernel.org
Fixes: 247b365dc8dc ("rust: add `kernel` crate")
Signed-off-by: David Gow 
Reviewed-by: Gary Guo 
Reviewed-by: Björn Roy Baron 
Reviewed-by: Vincenzo Palazzo 
[Applied `rustfmt`]
Signed-off-by: Miguel Ojeda

rust: print: avoid evaluating arguments in `pr_*` macros in `unsafe` blocks

2023-01-15T23:54:35+00:00

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 
Reported-by: Domen Puncer Kugler 
Link: https://github.com/Rust-for-Linux/linux/issues/479
Signed-off-by: Miguel Ojeda 
Reviewed-by: Boqun Feng 
Reviewed-by: Gary Guo 
Reviewed-by: Björn Roy Baron 
Reviewed-by: Vincenzo Palazzo

rust: print: add `pr_cont!` macro

2022-12-01T19:12:44+00:00

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 
Signed-off-by: Adam Bratschi-Kaye 
Co-developed-by: Wedson Almeida Filho 
Signed-off-by: Wedson Almeida Filho 
Co-developed-by: Gary Guo 
Signed-off-by: Gary Guo 
Reviewed-by: Wei Liu 
Reviewed-by: Sergio González Collado 
Signed-off-by: Miguel Ojeda

rust: print: add more `pr_*!` levels

2022-12-01T19:12:14+00:00

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 
Signed-off-by: Adam Bratschi-Kaye 
Co-developed-by: Wedson Almeida Filho 
Signed-off-by: Wedson Almeida Filho 
Co-developed-by: Gary Guo 
Signed-off-by: Gary Guo 
Reviewed-by: Boqun Feng 
Reviewed-by: Wei Liu 
Reviewed-by: Sergio Gonzalez Collado 
Signed-off-by: Miguel Ojeda

rust: add `kernel` crate

2022-09-28T06:58:24+00:00

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 
Co-developed-by: Alex Gaynor 
Signed-off-by: Alex Gaynor 
Co-developed-by: Geoffrey Thomas 
Signed-off-by: Geoffrey Thomas 
Co-developed-by: Finn Behrens 
Signed-off-by: Finn Behrens 
Co-developed-by: Adam Bratschi-Kaye 
Signed-off-by: Adam Bratschi-Kaye 
Co-developed-by: Sven Van Asbroeck 
Signed-off-by: Sven Van Asbroeck 
Co-developed-by: Gary Guo 
Signed-off-by: Gary Guo 
Co-developed-by: Boris-Chengbiao Zhou 
Signed-off-by: Boris-Chengbiao Zhou 
Co-developed-by: Boqun Feng 
Signed-off-by: Boqun Feng 
Co-developed-by: Fox Chen 
Signed-off-by: Fox Chen 
Co-developed-by: Viktor Garske 
Signed-off-by: Viktor Garske 
Co-developed-by: Dariusz Sosnowski 
Signed-off-by: Dariusz Sosnowski 
Co-developed-by: Léo Lanteri Thauvin 
Signed-off-by: Léo Lanteri Thauvin 
Co-developed-by: Niklas Mohrin 
Signed-off-by: Niklas Mohrin 
Co-developed-by: Milan Landaverde 
Signed-off-by: Milan Landaverde 
Co-developed-by: Morgan Bartlett 
Signed-off-by: Morgan Bartlett 
Co-developed-by: Maciej Falkowski 
Signed-off-by: Maciej Falkowski 
Co-developed-by: Nándor István Krácser 
Signed-off-by: Nándor István Krácser 
Co-developed-by: David Gow 
Signed-off-by: David Gow 
Co-developed-by: John Baublitz 
Signed-off-by: John Baublitz 
Co-developed-by: Björn Roy Baron 
Signed-off-by: Björn Roy Baron 
Signed-off-by: Wedson Almeida Filho 
Co-developed-by: Miguel Ojeda 
Signed-off-by: Miguel Ojeda