| 04866494 | 04-Sep-2024 |
Miguel Ojeda <[email protected]> |
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 <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| 139d3965 | 04-Sep-2024 |
Miguel Ojeda <[email protected]> |
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 <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Tested-by: Gary Guo <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| 7d2fc5a4 | 26-Aug-2024 |
Jon Mulder <[email protected]> |
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 <[email protected]>
Closes: https://github.com/Rust-for-Linux/linux/issues/1103
Fixes: d07479b211b7 ("docs: add Rust documentation")
Signed-off-by: Jon Mulder <[email protected]>
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 <[email protected]>
show more ...
|
| b2bf463e | 18-Aug-2024 |
Miguel Ojeda <[email protected]> |
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/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| 0eef6ec5 | 18-Aug-2024 |
Miguel Ojeda <[email protected]> |
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 <[email protected]>
Acked-by: Konstantin Ryabitsev <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| b1263411 | 09-Jul-2024 |
Miguel Ojeda <[email protected]> |
docs: rust: quick-start: add section on Linux distributions
Now that we are starting to support several Rust compiler and `bindgen`
versions, there is a good chance some Linux distributions work out
docs: rust: quick-start: add section on Linux distributions
Now that we are starting to support several Rust compiler and `bindgen`
versions, there is a good chance some Linux distributions work out of
the box.
Thus, provide some instructions on how to set the toolchain up for a
few major Linux distributions. This simplifies the setup users need to
build the kernel.
In addition, add an introduction to the document so that it is easier
to understand its structure and move the LLVM+Rust kernel.org toolchains
paragraph there (removing "depending on the Linux version"). We may want
to reorganize the document or split it in the future, but I wanted to
focus this commit on the new information added about each particular
distribution.
Finally, remove the `rustup`'s components mention in `changes.rst` since
users do not need it if they install the toolchain via the distributions
(and anyway it was too detailed for that main document).
Cc: Jan Alexander Steffens <[email protected]>
Cc: Johannes Löthberg <[email protected]>
Cc: Fabian Grünbichler <[email protected]>
Cc: Josh Stone <[email protected]>
Cc: Randy Barlow <[email protected]>
Cc: Anna (navi) Figueiredo Gomes <[email protected]>
Cc: Matoro Mahri <[email protected]>
Cc: Ryan Scheel <[email protected]>
Cc: figsoda <[email protected]>
Cc: Jörg Thalheim <[email protected]>
Cc: Theodore Ni <[email protected]>
Cc: Winter <[email protected]>
Cc: William Brown <[email protected]>
Cc: Xiaoguang Wang <[email protected]>
Cc: Andrea Righi <[email protected]>
Cc: Zixing Liu <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Tested-by: Andreas Hindborg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| c844fa64 | 09-Jul-2024 |
Miguel Ojeda <[email protected]> |
rust: start supporting several `bindgen` versions
With both the workaround for `bindgen` 0.69.0 and the warning about
0.66.0 and 0.66.1 in place, start supporting several `bindgen` versions,
like it
rust: start supporting several `bindgen` versions
With both the workaround for `bindgen` 0.69.0 and the warning about
0.66.0 and 0.66.1 in place, start supporting several `bindgen` versions,
like it was done for the Rust compiler in a previous patch.
All other versions, including the latest 0.69.4, build without errors.
The `bindgen` project, like Rust, has also agreed to have the kernel
in their CI [1] -- thanks! This should help both projects: `bindgen`
will be able to detect early issues like those mentioned above, and the
kernel will be very likely build with new releases (at least for the
basic configuration being tested).
Link: https://github.com/rust-lang/rust-bindgen/pull/2851 [1]
Tested-by: Benno Lossin <[email protected]>
Tested-by: Andreas Hindborg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| d49082fa | 09-Jul-2024 |
Miguel Ojeda <[email protected]> |
rust: avoid assuming a particular `bindgen` build
`bindgen`'s logic to find `libclang` (via `clang-sys`) may change over
time, and depends on how it was built (e.g. Linux distributions may decide
to
rust: avoid assuming a particular `bindgen` build
`bindgen`'s logic to find `libclang` (via `clang-sys`) may change over
time, and depends on how it was built (e.g. Linux distributions may decide
to build it differently, and we are going to provide documentation on
installing it via distributions later in this series).
Therefore, clarify that `bindgen` may be built in several ways and
simplify the documentation by only mentioning the most prominent
environment variable (`LIBCLANG_PATH`) as an example on how to tweak the
search of the library at runtime (i.e. when `bindgen` is built as our
documentation explains). This also avoids duplicating the documentation,
like `bindgen` itself does (i.e. it refers to `clang-sys`).
Similarly, replace the test we had for this (which used the real program)
with a mocked one, to avoid depending on the particular build as well.
Tested-by: Benno Lossin <[email protected]>
Tested-by: Andreas Hindborg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| 63b27f4a | 09-Jul-2024 |
Miguel Ojeda <[email protected]> |
rust: start supporting several compiler versions
It is time to start supporting several Rust compiler versions and thus
establish a minimum Rust version.
We may still want to upgrade the minimum so
rust: start supporting several compiler versions
It is time to start supporting several Rust compiler versions and thus
establish a minimum Rust version.
We may still want to upgrade the minimum sometimes in the beginning since
there may be important features coming into the language that improve
how we write code (e.g. field projections), which may or may not make
sense to support conditionally.
We will start with a window of two stable releases, and widen it over
time. Thus this patch does not move the current minimum (1.78.0), but
instead adds support for the recently released 1.79.0.
This should already be enough for kernel developers in distributions that
provide recent Rust compiler versions routinely, such as Arch Linux,
Debian Unstable (outside the freeze period), Fedora Linux, Gentoo
Linux (especially the testing channel), Nix (unstable) and openSUSE
Tumbleweed. See the documentation patch about it later in this series.
In addition, Rust for Linux is now being built-tested in Rust's pre-merge
CI [1]. That is, every change that is attempting to land into the Rust
compiler is tested against the kernel, and it is merged only if it passes
-- thanks to the Rust project for that!
Thus, with the pre-merge CI in place, both projects hope to avoid
unintentional changes to Rust that break the kernel. This means that,
in general, apart from intentional changes on their side (that we will
need to workaround conditionally on our side), the upcoming Rust compiler
versions should generally work.
For instance, currently, the beta (1.80.0) and nightly (1.81.0) branches
work as well.
Of course, the Rust for Linux CI job in the Rust toolchain may still need
to be temporarily disabled for different reasons, but the intention is
to help bring Rust for Linux into stable Rust.
Link: https://github.com/rust-lang/rust/pull/125209 [1]
Reviewed-by: Finn Behrens <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Tested-by: Andreas Hindborg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| 9ffc80c8 | 28-May-2024 |
Miguel Ojeda <[email protected]> |
kbuild: rust: remove now-unneeded `rusttest` custom sysroot handling
Since we dropped our custom `alloc` in commit 9d0441bab775 ("rust: alloc:
remove our fork of the `alloc` crate"), there is no nee
kbuild: rust: remove now-unneeded `rusttest` custom sysroot handling
Since we dropped our custom `alloc` in commit 9d0441bab775 ("rust: alloc:
remove our fork of the `alloc` crate"), there is no need anymore to keep
the custom sysroot hack.
Thus delete it, which makes the target way simpler and faster too.
This also means we are not using Cargo for anything at the moment,
and that no download is required anymore, so update the main `Makefile`
and the documentation accordingly.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|