| 4d320e30 | 14-Mar-2025 |
Danilo Krummrich <[email protected]> |
rust: platform: fix unrestricted &mut platform::Device
As by now, platform::Device is implemented as:
#[derive(Clone)]
pub struct Device(ARef<device::Device>);
This may be convenient, but has th
rust: platform: fix unrestricted &mut platform::Device
As by now, platform::Device is implemented as:
#[derive(Clone)]
pub struct Device(ARef<device::Device>);
This may be convenient, but has the implication that drivers can call
device methods that require a mutable reference concurrently at any
point of time.
Instead define platform::Device as
pub struct Device<Ctx: DeviceContext = Normal>(
Opaque<bindings::platform_dev>,
PhantomData<Ctx>,
);
and manually implement the AlwaysRefCounted trait.
With this we can implement methods that should only be called from
bus callbacks (such as probe()) for platform::Device<Core>. Consequently,
we make this type accessible in bus callbacks only.
Arbitrary references taken by the driver are still of type
ARef<platform::Device> and hence don't provide access to methods that are
reserved for bus callbacks.
Fixes: 683a63befc73 ("rust: platform: add basic platform device / driver abstractions")
Reviewed-by: Benno Lossin <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Acked-by: Boqun Feng <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
| 95cb0cb5 | 27-Feb-2025 |
Lyude Paul <[email protected]> |
rust/faux: Add missing parent argument to Registration::new()
A little late in the review of the faux device interface, we added the
ability to specify a parent device when creating new faux devices
rust/faux: Add missing parent argument to Registration::new()
A little late in the review of the faux device interface, we added the
ability to specify a parent device when creating new faux devices - but
this never got ported over to the rust bindings. So, let's add the missing
argument now so we don't have to convert other users later down the line.
Signed-off-by: Lyude Paul <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
| 47cb6bf7 | 03-Dec-2024 |
Xiangfei Ding <[email protected]> |
rust: use derive(CoercePointee) on rustc >= 1.84.0
The `kernel` crate relies on both `coerce_unsized` and `dispatch_from_dyn`
unstable features.
Alice Ryhl has proposed [1] the introduction of the
rust: use derive(CoercePointee) on rustc >= 1.84.0
The `kernel` crate relies on both `coerce_unsized` and `dispatch_from_dyn`
unstable features.
Alice Ryhl has proposed [1] the introduction of the unstable macro
`SmartPointer` to reduce such dependence, along with a RFC patch [2].
Since Rust 1.81.0 this macro, later renamed to `CoercePointee` in
Rust 1.84.0 [3], has been fully implemented with the naming discussion
resolved.
This feature is now on track to stabilization in the language.
In order to do so, we shall start using this macro in the `kernel` crate
to prove the functionality and utility of the macro as the justification
of its stabilization.
This patch makes this switch in such a way that the crate remains
backward compatible with older Rust compiler versions,
via the new Kconfig option `RUSTC_HAS_COERCE_POINTEE`.
A minimal demonstration example is added to the
`samples/rust/rust_print_main.rs` module.
Link: https://rust-lang.github.io/rfcs/3621-derive-smart-pointer.html [1]
Link: https://lore.kernel.org/all/[email protected]/ [2]
Link: https://github.com/rust-lang/rust/pull/131284 [3]
Signed-off-by: Xiangfei Ding <[email protected]>
Reviewed-by: Fiona Behrens <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Fixed version to 1.84. Renamed option to `RUSTC_HAS_COERCE_POINTEE`
to match `CC_HAS_*` ones. Moved up new config option, closer to the
`CC_HAS_*` ones. Simplified Kconfig line. Fixed typos and slightly
reworded example and commit. Added Link to PR. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| 8d9b095b | 13-Dec-2024 |
Lee Jones <[email protected]> |
samples: rust_misc_device: Provide an example C program to exercise functionality
Here is the expected output (manually spliced together):
USERSPACE: Opening /dev/rust-misc-device for reading and w
samples: rust_misc_device: Provide an example C program to exercise functionality
Here is the expected output (manually spliced together):
USERSPACE: Opening /dev/rust-misc-device for reading and writing
KERNEL: rust_misc_device: Opening Rust Misc Device Sample
USERSPACE: Calling Hello
KERNEL: rust_misc_device: IOCTLing Rust Misc Device Sample
KERNEL: rust_misc_device: -> Hello from the Rust Misc Device
USERSPACE: Fetching initial value
KERNEL: rust_misc_device: IOCTLing Rust Misc Device Sample
KERNEL: rust_misc_device: -> Copying data to userspace (value: 0)
USERSPACE: Submitting new value (1)
KERNEL: rust_misc_device: IOCTLing Rust Misc Device Sample
KERNEL: rust_misc_device: -> Copying data from userspace (value: 1)
USERSPACE: Fetching new value
KERNEL: rust_misc_device: IOCTLing Rust Misc Device Sample
KERNEL: rust_misc_device: -> Copying data to userspace (value: 1)
USERSPACE: Attempting to call in to an non-existent IOCTL
KERNEL: rust_misc_device: IOCTLing Rust Misc Device Sample
KERNEL: rust_misc_device: -> IOCTL not recognised: 20992
USERSPACE: ioctl: Succeeded to fail - this was expected: Inappropriate ioctl for device
USERSPACE: Closing /dev/rust-misc-device
KERNEL: rust_misc_device: Exiting the Rust Misc Device Sample
USERSPACE: Success
Signed-off-by: Lee Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
| 22193c58 | 11-Nov-2024 |
Miguel Ojeda <[email protected]> |
samples: rust: fix `rust_print` build making it a combined module
The `rust_print` module, when built as a module, fails to build with:
ERROR: modpost: missing MODULE_LICENSE() in samples/rust/
samples: rust: fix `rust_print` build making it a combined module
The `rust_print` module, when built as a module, fails to build with:
ERROR: modpost: missing MODULE_LICENSE() in samples/rust/rust_print_events.o
ERROR: modpost: "__tracepoint_rust_sample_loaded" [samples/rust/rust_print.ko] undefined!
ERROR: modpost: "rust_do_trace_rust_sample_loaded" [samples/rust/rust_print.ko] undefined!
Fix it by building it as a combined one.
Cc: Masami Hiramatsu <[email protected]>
Cc: Alex Gaynor <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Boqun Feng <[email protected]>
Cc: Gary Guo <[email protected]>
Cc: Björn Roy Baron <[email protected]>
Cc: Benno Lossin <[email protected]>
Cc: Andreas Hindborg <[email protected]>
Cc: Alice Ryhl <[email protected]>
Cc: Trevor Gross <[email protected]>
Cc: "Linux Next Mailing List" <[email protected]>
Link: https://lore.kernel.org/[email protected]
Reported-by: Stephen Rothwell <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Fixes: 91d39024e1b0 ("rust: samples: add tracepoint to Rust sample")
Signed-off-by: Miguel Ojeda <[email protected]>
Signed-off-by: Steven Rostedt (Google) <[email protected]>
show more ...
|
| 1f9ed172 | 04-Sep-2024 |
Miguel Ojeda <[email protected]> |
rust: start using the `#[expect(...)]` attribute
In Rust, it is possible to `allow` particular warnings (diagnostics,
lints) locally, making the compiler ignore instances of a given warning
within a
rust: start using the `#[expect(...)]` attribute
In Rust, it is possible to `allow` particular warnings (diagnostics,
lints) locally, making the compiler ignore instances of a given warning
within a given function, module, block, etc.
It is similar to `#pragma GCC diagnostic push` + `ignored` + `pop` in C:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-function"
static void f(void) {}
#pragma GCC diagnostic pop
But way less verbose:
#[allow(dead_code)]
fn f() {}
By that virtue, it makes it possible to comfortably enable more
diagnostics by default (i.e. outside `W=` levels) that may have some
false positives but that are otherwise quite useful to keep enabled to
catch potential mistakes.
The `#[expect(...)]` attribute [1] takes this further, and makes the
compiler warn if the diagnostic was _not_ produced. For instance, the
following will ensure that, when `f()` is called somewhere, we will have
to remove the attribute:
#[expect(dead_code)]
fn f() {}
If we do not, we get a warning from the compiler:
warning: this lint expectation is unfulfilled
--> x.rs:3:10
|
3 | #[expect(dead_code)]
| ^^^^^^^^^
|
= note: `#[warn(unfulfilled_lint_expectations)]` on by default
This means that `expect`s do not get forgotten when they are not needed.
See the next commit for more details, nuances on its usage and
documentation on the feature.
The attribute requires the `lint_reasons` [2] unstable feature, but it
is becoming stable in 1.81.0 (to be released on 2024-09-05) and it has
already been useful to clean things up in this patch series, finding
cases where the `allow`s should not have been there.
Thus, enable `lint_reasons` and convert some of our `allow`s to `expect`s
where possible.
This feature was also an example of the ongoing collaboration between
Rust and the kernel -- we tested it in the kernel early on and found an
issue that was quickly resolved [3].
Cc: Fridtjof Stoldt <[email protected]>
Cc: Urgau <[email protected]>
Link: https://rust-lang.github.io/rfcs/2383-lint-reasons.html#expect-lint-attribute [1]
Link: https://github.com/rust-lang/rust/issues/54503 [2]
Link: https://github.com/rust-lang/rust/issues/114557 [3]
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Trevor Gross <[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 ...
|
| b13c9880 | 10-Nov-2022 |
Gary Guo <[email protected]> |
rust: macros: take string literals in `module!`
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!` l
rust: macros: take string literals in `module!`
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]>
show more ...
|