| a3b23473 | 02-May-2025 |
Miguel Ojeda <ojeda@kernel.org> |
Documentation: rust: testing: add docs on the new KUnit `#[test]` tests
There was no documentation yet on the KUnit-based `#[test]`s.
Thus add it now.
It includes an explanation about the `assert*
Documentation: rust: testing: add docs on the new KUnit `#[test]` tests
There was no documentation yet on the KUnit-based `#[test]`s.
Thus add it now.
It includes an explanation about the `assert*!` macros being mapped to
KUnit and the support for `-> Result` introduced in these series.
Reviewed-by: David Gow <davidgow@google.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/20250502215133.1923676-8-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
| 0a8d4eab | 02-May-2025 |
Miguel Ojeda <ojeda@kernel.org> |
Documentation: rust: rename `#[test]`s to "`rusttest` host tests"
Now that `rusttest`s are not really used much, clarify the section of
the documentation that describes them.
In addition, free the
Documentation: rust: rename `#[test]`s to "`rusttest` host tests"
Now that `rusttest`s are not really used much, clarify the section of
the documentation that describes them.
In addition, free the section name for the KUnit-based `#[test]`s that
will be added afterwards. To do so, rename the section into `rusttest`
host tests.
Reviewed-by: David Gow <davidgow@google.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/20250502215133.1923676-7-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
| 3d5bef5d | 13-Apr-2025 |
Miguel Ojeda <ojeda@kernel.org> |
rust: add C FFI types to the prelude
Rust kernel code is supposed to use the custom mapping of C FFI types,
i.e. those from the `ffi` crate, rather than the ones coming from `core`.
Thus, to minimi
rust: add C FFI types to the prelude
Rust kernel code is supposed to use the custom mapping of C FFI types,
i.e. those from the `ffi` crate, rather than the ones coming from `core`.
Thus, to minimize mistakes and to simplify the code everywhere, just
provide them in the `kernel` prelude and ask in the Coding Guidelines
to use them directly, i.e. as a single segment path.
After this lands, we can start cleaning up the existing users.
Ideally, we would use something like Clippy's `disallowed-types` to
prevent the use of the `core` ones, but that one sees through aliases.
Link: https://lore.kernel.org/rust-for-linux/CANiq72kc4gzfieD-FjuWfELRDXXD2vLgPv4wqk3nt4pjdPQ=qg@mail.gmail.com/
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250413005650.1745894-1-ojeda@kernel.org
[ Reworded content of the documentation to focus on how to use the
aliases first. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
| f2e413f0 | 06-Feb-2025 |
Alban Kurti <kurti@invicto.ai> |
rust: docs: add missing newline to printing macro examples
Fix adding a newline at the end of the usage of pr_info! in the
documentation
Fixes: e3c3d34507c7 ("docs: rust: Add description of Rust do
rust: docs: add missing newline to printing macro examples
Fix adding a newline at the end of the usage of pr_info! in the
documentation
Fixes: e3c3d34507c7 ("docs: rust: Add description of Rust documentation test as KUnit ones")
Reported-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://github.com/Rust-for-Linux/linux/issues/1139
Signed-off-by: Alban Kurti <kurti@invicto.ai>
Reviewed-by: David Gow <davidgow@google.com>
Link: https://lore.kernel.org/r/20250206-printing_fix-v3-1-a85273b501ae@invicto.ai
[ Replaced Closes with Link since it fixes part of the issue. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
| 04866494 | 04-Sep-2024 |
Miguel Ojeda <ojeda@kernel.org> |
Documentation: rust: discuss `#[expect(...)]` in the guidelines
Discuss `#[expect(...)]` in the Lints sections of the coding guidelines
document, which is an upcoming feature in Rust 1.81.0, and exp
Documentation: rust: discuss `#[expect(...)]` in the guidelines
Discuss `#[expect(...)]` in the Lints sections of the coding guidelines
document, which is an upcoming feature in Rust 1.81.0, and explain that
it is generally to be preferred over `allow` unless there is a reason
not to use it (e.g. conditional compilation being involved).
Tested-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://lore.kernel.org/r/20240904204347.168520-19-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
| 139d3965 | 04-Sep-2024 |
Miguel Ojeda <ojeda@kernel.org> |
Documentation: rust: add coding guidelines on lints
In the C side, disabling diagnostics locally, i.e. within the source code,
is rare (at least in the kernel). Sometimes warnings are manipulated
vi
Documentation: rust: add coding guidelines on lints
In the C side, disabling diagnostics locally, i.e. within the source code,
is rare (at least in the kernel). Sometimes warnings are manipulated
via the flags at the translation unit level, but that is about it.
In Rust, it is easier to change locally the "level" of lints
(e.g. allowing them locally). In turn, this means it is easier to
globally enable more lints that may trigger a few false positives here
and there that need to be allowed locally, but that generally can spot
issues or bugs.
Thus document this.
Reviewed-by: Trevor Gross <tmgross@umich.edu>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Tested-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://lore.kernel.org/r/20240904204347.168520-17-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
| 93dc3be1 | 02-Sep-2024 |
Miguel Ojeda <ojeda@kernel.org> |
docs: rust: include other expressions in conditional compilation section
Expand the conditional compilation section to explain how to support
other expressions, such as testing whether `RUSTC_VERSIO
docs: rust: include other expressions in conditional compilation section
Expand the conditional compilation section to explain how to support
other expressions, such as testing whether `RUSTC_VERSION` is at least
a given version, which requires a numerical comparison that Rust's `cfg`
predicates do not support (yet?).
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Tested-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Masahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20240902165535.1101978-7-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
| 7d2fc5a4 | 26-Aug-2024 |
Jon Mulder <jon.e.mulder@gmail.com> |
docs: rust: remove unintended blockquote in Quick Start
Remove indentation within the "Hacking" section of the Rust Quick Start
guide, i.e. remove a `<blockquote>` HTML element from the rendered
doc
docs: rust: remove unintended blockquote in Quick Start
Remove indentation within the "Hacking" section of the Rust Quick Start
guide, i.e. remove a `<blockquote>` HTML element from the rendered
documentation.
Reported-by: Miguel Ojeda <ojeda@kernel.org>
Closes: https://github.com/Rust-for-Linux/linux/issues/1103
Fixes: d07479b211b7 ("docs: add Rust documentation")
Signed-off-by: Jon Mulder <jon.e.mulder@gmail.com>
Link: https://lore.kernel.org/r/20240826-pr-docs-rust-remove-quickstart-blockquote-v1-1-c51317d8d71a@gmail.com
[ Added Fixes tag, reworded slightly and matched title to a previous,
similar commit. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
| b2bf463e | 18-Aug-2024 |
Miguel Ojeda <ojeda@kernel.org> |
docs: rust: improve main page introducing a "Code documentation" section
Clean the "Rust" main page by introducing a 'Code documentation" section
to separate it from the rest of the text above.
In
docs: rust: improve main page introducing a "Code documentation" section
Clean the "Rust" main page by introducing a 'Code documentation" section
to separate it from the rest of the text above.
In addition, introduce the "Rust code documentation" term, which may be
clearer than referring to a potentially unknown tool.
Furthermore, for the HTML case, homogenize both `rustdoc` and
non-`rustdoc` cases and use the term introduced above instead.
Then, always generate the pregenerated version part, since now there
is a section that is always generated and thus makes sense to do so.
Finally, finish the new section with a link to more details about the
Rust code documentation.
The intention is that:
- The non-HTML case mentions the code documentation too, making it
more prominent for readers of non-HTML docs.
- Both HTML cases read more naturally.
- The pregenerated version is always mentioned, since it is likely
useful for readers of non-HTML docs.
Link: https://lore.kernel.org/r/20240818141200.386899-2-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|
| 0eef6ec5 | 18-Aug-2024 |
Miguel Ojeda <ojeda@kernel.org> |
docs: rust: link to https://rust.docs.kernel.org
The Rust code documentation (i.e. `rustdoc`-generated docs) is now
available at:
https://rust.docs.kernel.org
Thus document it and remove the `
docs: rust: link to https://rust.docs.kernel.org
The Rust code documentation (i.e. `rustdoc`-generated docs) is now
available at:
https://rust.docs.kernel.org
Thus document it and remove the `TODO` line.
The generation uses a particular kernel configuration, based on x86_64,
which may get tweaked over time. Older tags, and how they are generated,
may also change in the future. We may consider freezing them at some
point, but for the moment, the content should not be considered immutable.
Thanks Konstantin for the support setting it up!
Cc: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Acked-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Link: https://lore.kernel.org/r/20240818141200.386899-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
show more ...
|