rust: kunit: allow to know if we are in a test

In some cases, we need to call test-only code from outside the test
case, for example, to mock a function or a module.

In order to check whether we ar

rust: kunit: allow to know if we are in a test

In some cases, we need to call test-only code from outside the test
case, for example, to mock a function or a module.

In order to check whether we are in a test or not, we need to test if
`CONFIG_KUNIT` is set.
Unfortunately, we cannot rely only on this condition because:
- a test could be running in another thread,
- some distros compile KUnit in production kernels, so checking at runtime
that `current->kunit_test != NULL` is required.

Forturately, KUnit provides an optimised check in
`kunit_get_current_test()`, which checks CONFIG_KUNIT, a global static
key, and then the current thread's running KUnit test.

Add a safe wrapper function around this to know whether or not we are in
a KUnit test and examples showing how to mock a function and a module.

Signed-off-by: José Expósito <[email protected]>
Co-developed-by: Miguel Ojeda <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>
Co-developed-by: David Gow <[email protected]>
Signed-off-by: David Gow <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: macros: add macro to easily run KUnit tests

Add a new procedural macro (`#[kunit_tests(kunit_test_suit_name)]`) to
run KUnit tests using a user-space like syntax.

The macro, that should be us

rust: macros: add macro to easily run KUnit tests

Add a new procedural macro (`#[kunit_tests(kunit_test_suit_name)]`) to
run KUnit tests using a user-space like syntax.

The macro, that should be used on modules, transforms every `#[test]`
in a `kunit_case!` and adds a `kunit_unsafe_test_suite!` registering
all of them.

The only difference with user-space tests is that instead of using
`#[cfg(test)]`, `#[kunit_tests(kunit_test_suit_name)]` is used.

Note that `#[cfg(CONFIG_KUNIT)]` is added so the test module is not
compiled when `CONFIG_KUNIT` is set to `n`.

Reviewed-by: David Gow <[email protected]>
Signed-off-by: José Expósito <[email protected]>
Co-developed-by: Boqun Feng <[email protected]>
Signed-off-by: Boqun Feng <[email protected]>
Co-developed-by: Miguel Ojeda <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>
Reviewed-by: Tamir Duberstein <[email protected]>
Signed-off-by: David Gow <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Removed spurious (in rendered form) newline in docs. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: kunit: add KUnit case and suite macros

Add a couple of Rust const functions and macros to allow to develop
KUnit tests without relying on generated C code:

- The `kunit_unsafe_test_suite!` R

rust: kunit: add KUnit case and suite macros

Add a couple of Rust const functions and macros to allow to develop
KUnit tests without relying on generated C code:

- The `kunit_unsafe_test_suite!` Rust macro is similar to the
`kunit_test_suite` C macro. It requires a NULL-terminated array of
test cases (see below).
- The `kunit_case` Rust function is similar to the `KUNIT_CASE` C macro.
It generates as case from the name and function.
- The `kunit_case_null` Rust function generates a NULL test case, which
is to be used as delimiter in `kunit_test_suite!`.

While these functions and macros can be used on their own, a future
patch will introduce another macro to create KUnit tests using a
user-space like syntax.

Signed-off-by: José Expósito <[email protected]>
Co-developed-by: Matt Gilbride <[email protected]>
Signed-off-by: Matt Gilbride <[email protected]>
Co-developed-by: Miguel Ojeda <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>
Co-developed-by: David Gow <[email protected]>
Signed-off-by: David Gow <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Applied Markdown in comment. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: platform: impl Send + Sync for platform::Device

Commit 4d320e30ee04 ("rust: platform: fix unrestricted &mut
platform::Device") changed the definition of platform::Device and
discarded the impl

rust: platform: impl Send + Sync for platform::Device

Commit 4d320e30ee04 ("rust: platform: fix unrestricted &mut
platform::Device") changed the definition of platform::Device and
discarded the implicitly derived Send and Sync traits.

This isn't required by upstream code yet, and hence did not cause any
issues. However, it is relied on by upcoming drivers, hence add it back
in.

Signed-off-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

rust: pci: impl Send + Sync for pci::Device

Commit 7b948a2af6b5 ("rust: pci: fix unrestricted &mut pci::Device")
changed the definition of pci::Device and discarded the implicitly
derived Send and S

rust: pci: impl Send + Sync for pci::Device

Commit 7b948a2af6b5 ("rust: pci: fix unrestricted &mut pci::Device")
changed the definition of pci::Device and discarded the implicitly
derived Send and Sync traits.

This isn't required by upstream code yet, and hence did not cause any
issues. However, it is relied on by upcoming drivers, hence add it back
in.

Signed-off-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

rust: optimize rust symbol generation for SeqFile

When build the kernel using the llvm-18.1.3-rust-1.85.0-x86_64
with ARCH=arm64, the following symbols are generated:

$nm vmlinux | grep ' _R'.*SeqF

rust: optimize rust symbol generation for SeqFile

When build the kernel using the llvm-18.1.3-rust-1.85.0-x86_64
with ARCH=arm64, the following symbols are generated:

$nm vmlinux | grep ' _R'.*SeqFile | rustfilt
ffff8000805b78ac T <kernel::seq_file::SeqFile>::call_printf

This Rust symbol is trivial wrappers around the C functions seq_printf.
It doesn't make sense to go through a trivial wrapper for its functions,
so mark it inline.

Link: https://github.com/Rust-for-Linux/linux/issues/1145
Suggested-by: Alice Ryhl <[email protected]>
Co-developed-by: Grace Deng <[email protected]>
Signed-off-by: Grace Deng <[email protected]>
Signed-off-by: Kunwu Chan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Signed-off-by: Christian Brauner <[email protected]>

show more ...

rust: file: optimize rust symbol generation for FileDescriptorReservation

When build the kernel using the llvm-18.1.3-rust-1.85.0-x86_64
with ARCH=arm64, the following symbols are generated:

$ nm v

rust: file: optimize rust symbol generation for FileDescriptorReservation

When build the kernel using the llvm-18.1.3-rust-1.85.0-x86_64
with ARCH=arm64, the following symbols are generated:

$ nm vmlinux | grep ' _R'.*FileDescriptorReservation | rustfilt
... T <kernel::fs::file::FileDescriptorReservation>::fd_install
... T <kernel::fs::file::FileDescriptorReservation>::get_unused_fd_flags
... T <kernel::fs::file::FileDescriptorReservation as core::ops::drop::Drop>::drop

These Rust symbols are trivial wrappers around the C functions
fd_install, put_unused_fd and put_task_struct. It
doesn't make sense to go through a trivial wrapper for these
functions, so mark them inline.

Link: https://github.com/Rust-for-Linux/linux/issues/1145
Suggested-by: Alice Ryhl <[email protected]>
Co-developed-by: Grace Deng <[email protected]>
Signed-off-by: Grace Deng <[email protected]>
Signed-off-by: Kunwu Chan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Alice Ryhl <[email protected]>
Signed-off-by: Christian Brauner <[email protected]>

show more ...

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 ...

rust: pci: fix unrestricted &mut pci::Device

As by now, pci::Device is implemented as:

#[derive(Clone)]
pub struct Device(ARef<device::Device>);

This may be convenient, but has the implication t

rust: pci: fix unrestricted &mut pci::Device

As by now, pci::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 pci::Device as

pub struct Device<Ctx: DeviceContext = Normal>(
Opaque<bindings::pci_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 pci::Device<Core>. Consequently, we
make this type accessible in bus callbacks only.

Arbitrary references taken by the driver are still of type
ARef<pci::Device> and hence don't provide access to methods that are
reserved for bus callbacks.

Fixes: 1bd8b6b2c5d3 ("rust: pci: add basic PCI 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 ...

rust: device: implement device context marker

Some bus device functions should only be called from bus callbacks,
such as probe(), remove(), resume(), suspend(), etc.

To ensure this add device cont

rust: device: implement device context marker

Some bus device functions should only be called from bus callbacks,
such as probe(), remove(), resume(), suspend(), etc.

To ensure this add device context marker structs, that can be used as
generics for bus device implementations.

Reviewed-by: Benno Lossin <[email protected]>
Suggested-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 ...

rust: pci: use to_result() in enable_device_mem()

Simplify enable_device_mem() by using to_result() to handle the return
value of the corresponding FFI call.

Reviewed-by: Benno Lossin <benno.lossin

rust: pci: use to_result() in enable_device_mem()

Simplify enable_device_mem() by using to_result() to handle the return
value of the corresponding FFI call.

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 ...

rust: make pin-init its own crate

Rename relative paths inside of the crate to still refer to the same
items, also rename paths inside of the kernel crate and adjust the build
system to build the cr

rust: make pin-init its own crate

Rename relative paths inside of the crate to still refer to the same
items, also rename paths inside of the kernel crate and adjust the build
system to build the crate.

[ Remove the `expect` (and thus the `lint_reasons` feature) since
the tree now uses `quote!` from `rust/macros/export.rs`. Remove the
`TokenStream` import removal, since it is now used as well.

In addition, temporarily (i.e. just for this commit) use an `--extern
force:alloc` to prevent an unknown `new_uninit` error in the `rustdoc`
target. For context, please see a similar case in:

https://lore.kernel.org/lkml/[email protected]/

And adjusted the message above. - Miguel ]

Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Fiona Behrens <[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 ...

rust: pin-init: fix documentation links

Before switching to compile the `pin-init` crate directly, change
any links that would be invalid to links that are valid both before and
after the switch.

S

rust: pin-init: fix documentation links

Before switching to compile the `pin-init` crate directly, change
any links that would be invalid to links that are valid both before and
after the switch.

Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Fiona Behrens <[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 ...

rust: add `ZeroableOption` and implement it instead of `Zeroable` for `Option<Box<T, A>>`

When making pin-init its own crate, `Zeroable` will no longer be defined
by the kernel crate and thus implem

rust: add `ZeroableOption` and implement it instead of `Zeroable` for `Option<Box<T, A>>`

When making pin-init its own crate, `Zeroable` will no longer be defined
by the kernel crate and thus implementing it for `Option<Box<T, A>>` is
no longer possible due to the orphan rule.
For this reason introduce a new `ZeroableOption` trait that circumvents
this problem.

Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Fiona Behrens <[email protected]>
Reviewed-by: Andreas Hindborg <[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 ...

rust: pin-init: move impl `Zeroable` for `Opaque` and `Option<KBox<T>>` into the kernel crate

In order to make pin-init a standalone crate, move kernel-specific code
directly into the kernel crate.

rust: pin-init: move impl `Zeroable` for `Opaque` and `Option<KBox<T>>` into the kernel crate

In order to make pin-init a standalone crate, move kernel-specific code
directly into the kernel crate. Since `Opaque<T>` and `KBox<T>` are part
of the kernel, move their `Zeroable` implementation into the kernel
crate.

Signed-off-by: Benno Lossin <[email protected]>
Tested-by: Andreas Hindborg <[email protected]>
Reviewed-by: Fiona Behrens <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: pin-init: move `InPlaceInit` and impls of `InPlaceWrite` into the kernel crate

In order to make pin-init a standalone crate, move kernel-specific code
directly into the kernel crate. This incl

rust: pin-init: move `InPlaceInit` and impls of `InPlaceWrite` into the kernel crate

In order to make pin-init a standalone crate, move kernel-specific code
directly into the kernel crate. This includes the `InPlaceInit<T>`
trait, its implementations and the implementations of `InPlaceWrite` for
`Arc` and `UniqueArc`. All of these use the kernel's error type which
will become unavailable in pin-init.

Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Fiona Behrens <[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 ...

rust: pin-init: move the default error behavior of `try_[pin_]init`

Move the ability to just write `try_pin_init!(Foo { a <- a_init })`
(note the missing `? Error` at the end) into the kernel crate.

rust: pin-init: move the default error behavior of `try_[pin_]init`

Move the ability to just write `try_pin_init!(Foo { a <- a_init })`
(note the missing `? Error` at the end) into the kernel crate.
Remove this notation from the pin-init crate, since the default when no
error is specified is the kernel-internal `Error` type. Instead add two
macros in the kernel crate that serve this default and are used instead
of the ones from `pin-init`.

This is done, because the `Error` type that is used as the default is
from the kernel crate and it thus prevents making the pin-init crate
standalone.

In order to not cause a build error due to a name overlap, the macros in
the pin-init crate are renamed, but this change is reverted in a future
commit when it is a standalone crate.

Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Fiona Behrens <[email protected]>
Reviewed-by: Andreas Hindborg <[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 ...

rust: add extensions to the pin-init crate and move relevant documentation there

In preparation of splitting off the pin-init crate from the kernel
crate, move all kernel-specific documentation from

rust: add extensions to the pin-init crate and move relevant documentation there

In preparation of splitting off the pin-init crate from the kernel
crate, move all kernel-specific documentation from pin-init back into
the kernel crate.

Also include an example from the user-space version [1] adapted to the
kernel.

The new `init.rs` file will also be populated by kernel-specific
extensions to the pin-init crate by the next commits.

Link: https://github.com/Rust-for-Linux/pin-init/blob/c1417c64c71229f0fd444d75e88f33e3c547c829/src/lib.rs#L161 [1]
Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Fiona Behrens <[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 ...

rust: move pin-init API into its own directory

In preparation of splitting off the pin-init crate from the kernel
crate, move all pin-init API code (including proc-macros) into
`rust/pin-init`.

Mov

rust: move pin-init API into its own directory

In preparation of splitting off the pin-init crate from the kernel
crate, move all pin-init API code (including proc-macros) into
`rust/pin-init`.

Moved modules have their import path adjusted via the `#[path = "..."]`
attribute. This allows the files to still be imported in the kernel
crate even though the files are in different directories.

Code that is moved out of files (but the file itself stays where it is)
is imported via the `include!` macro. This also allows the code to be
moved while still being part of the kernel crate.

Note that this commit moves the generics parsing code out of the GPL-2.0
file `rust/macros/helpers.rs` into the Apache-2.0 OR MIT file
`rust/pin_init/internal/src/helpers.rs`. I am the sole author of that
code and it already is available with that license at [1].
The same is true for the entry-points of the proc-macros `pin_data`,
`pinned_drop` and `derive_zeroable` in `rust/macros/lib.rs` that are
moved to `rust/pin_data/internal/src/lib.rs`. Although there are some
smaller patches that fix the doctests.

Link: https://github.com/Rust-for-Linux/pinned-init [1]
Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Andreas Hindborg <[email protected]>
Reviewed-by: Fiona Behrens <[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 ...

rust: init: disable doctests

The build system cannot handle doctests in the kernel crate in files
outside of `rust/kernel/`. Subsequent commits will move files out of
that directory, but will still

rust: init: disable doctests

The build system cannot handle doctests in the kernel crate in files
outside of `rust/kernel/`. Subsequent commits will move files out of
that directory, but will still compile them as part of the kernel crate.
Thus ignore all doctests in the to-be-moved files.

Leave tests disabled until they are separated into their own crate and
they stop causing breakage.

Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Fiona Behrens <[email protected]>
Reviewed-by: Andreas Hindborg <[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 ...

rust: error: extend the Result documentation

Extend the Result documentation by some guidelines and examples how
to handle Result error cases gracefully. And how to not handle them.

While at it fix

rust: error: extend the Result documentation

Extend the Result documentation by some guidelines and examples how
to handle Result error cases gracefully. And how to not handle them.

While at it fix one missing `Result` link in the existing documentation.

[ Moved links out-of-line for improved readability. Fixed `srctree`
link. Sorted out-of-line links. Added newlines for consistency
with other docs. Applied paragraph break suggestion. Reworded
slightly the docs in a couple places. Added Markdown.

In addition, added `#[allow(clippy::single_match)` for the first
example. It cannot be an `expect` since due to a difference introduced
in Rust 1.85.0 when there are comments in the arms of the `match`.
Reported it upstream, but it was intended:

https://github.com/rust-lang/rust-clippy/issues/14418

Perhaps Clippy will lint about it in the future, but without autofix:

https://github.com/rust-lang/rust-clippy/pull/14420

- Miguel ]

Link: https://lore.kernel.org/rust-for-linux/CANiq72keOdXy0LFKk9SzYWwSjiD710v=hQO4xi+5E4xNALa6cA@mail.gmail.com/
Signed-off-by: Dirk Behme <[email protected]>
Reviewed-by: Fiona Behrens <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: hrtimer: implement `HrTimerPointer` for `Arc`

Allow the use of intrusive `hrtimer` fields in structs that are managed by
an `Arc` by implementing `HrTimerPointer` and `RawTimerCallbck` for `Ar

rust: hrtimer: implement `HrTimerPointer` for `Arc`

Allow the use of intrusive `hrtimer` fields in structs that are managed by
an `Arc` by implementing `HrTimerPointer` and `RawTimerCallbck` for `Arc`.

Acked-by: Frederic Weisbecker <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Andreas Hindborg <[email protected]>

show more ...

rust: sync: add `Arc::as_ptr`

Add a method to get a pointer to the data contained in an `Arc`.

Reviewed-by: Lyude Paul <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by:

rust: sync: add `Arc::as_ptr`

Add a method to get a pointer to the data contained in an `Arc`.

Reviewed-by: Lyude Paul <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Andreas Hindborg <[email protected]>

show more ...

rust: hrtimer: introduce hrtimer support

Add support for intrusive use of the hrtimer system. For now,
only add support for embedding one timer per Rust struct.

The hrtimer Rust API is based on the

rust: hrtimer: introduce hrtimer support

Add support for intrusive use of the hrtimer system. For now,
only add support for embedding one timer per Rust struct.

The hrtimer Rust API is based on the intrusive style pattern introduced by
the Rust workqueue API.

Acked-by: Frederic Weisbecker <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Tamir Duberstein <[email protected]>
Reviewed-by: Lyude Paul <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Andreas Hindborg <[email protected]>

show more ...

rust/kernel/faux: mark Registration methods inline

When building the kernel on Arch Linux using on x86_64 with tools:
$ rustc --version
rustc 1.84.0 (9fc6b4312 2025-01-07)
$ clang --version
clang ve

rust/kernel/faux: mark Registration methods inline

When building the kernel on Arch Linux using on x86_64 with tools:
$ rustc --version
rustc 1.84.0 (9fc6b4312 2025-01-07)
$ clang --version
clang version 19.1.7
Target: x86_64-pc-linux-gnu

The following symbols are generated:
$ nm vmlinux | rg ' _R' | rustfilt | rg faux
ffffffff81959ae0 T <kernel::faux::Registration>::new
ffffffff81959b40 T <kernel::faux::Registration as core::ops::drop::Drop>::drop

However, these Rust symbols are wrappers around bindings in the C faux
code. Inlining these functions removes the middle-man wrapper function
After applying this patch, the above function signatures disappear.

Link: https://github.com/Rust-for-Linux/linux/issues/1145
Signed-off-by: Ethan Carter Edwards <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/jesg4yu7m6fvzmgg5tlsktrrjm36l4qsranto5mdmnucx4pvf3@nhvt4juw5es3
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...