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: 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: 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: init: add missing newline to pr_info! calls

Several pr_info! calls in rust/kernel/init.rs (both in code examples
and macro documentation) were missing a newline, causing logs to
run together.

rust: init: add missing newline to pr_info! calls

Several pr_info! calls in rust/kernel/init.rs (both in code examples
and macro documentation) were missing a newline, causing logs to
run together. This commit updates these calls to include a trailing
newline, improving readability and consistency with the C side.

Fixes: 6841d45a3030 ("rust: init: add `stack_pin_init!` macro")
Fixes: 7f8977a7fe6d ("rust: init: add `{pin_}chain` functions to `{Pin}Init<T, E>`")
Fixes: d0fdc3961270 ("rust: init: add `PinnedDrop` trait and macros")
Fixes: 4af84c6a85c6 ("rust: init: update expanded macro explanation")
Reported-by: Miguel Ojeda <[email protected]>
Link: https://github.com/Rust-for-Linux/linux/issues/1139
Signed-off-by: Alban Kurti <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Replaced Closes with Link since it fixes part of the issue. Added
one more Fixes tag (still same set of stable kernels). - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: init: fix `Zeroable` implementation for `Option<NonNull<T>>` and `Option<KBox<T>>`

According to [1], `NonNull<T>` and `#[repr(transparent)]` wrapper types
such as our custom `KBox<T>` have the

rust: init: fix `Zeroable` implementation for `Option<NonNull<T>>` and `Option<KBox<T>>`

According to [1], `NonNull<T>` and `#[repr(transparent)]` wrapper types
such as our custom `KBox<T>` have the null pointer optimization only if
`T: Sized`. Thus remove the `Zeroable` implementation for the unsized
case.

Link: https://doc.rust-lang.org/stable/std/option/index.html#representation [1]
Reported-by: Alice Ryhl <[email protected]>
Closes: https://lore.kernel.org/rust-for-linux/CAH5fLghL+qzrD8KiCF1V3vf2YcC6aWySzkmaE2Zzrnh1gKj-hw@mail.gmail.com/
Cc: [email protected] # v6.12+ (a custom patch will be needed for 6.6.y)
Fixes: 38cde0bd7b67 ("rust: init: add `Zeroable` trait and `init::zeroed` function")
Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Andreas Hindborg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Added Closes tag and moved up the Reported-by one. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: init: use explicit ABI to clean warning in future compilers

Starting with Rust 1.86.0 (currently in nightly, to be released on
2025-04-03), the `missing_abi` lint is warn-by-default [1]:

rust: init: use explicit ABI to clean warning in future compilers

Starting with Rust 1.86.0 (currently in nightly, to be released on
2025-04-03), the `missing_abi` lint is warn-by-default [1]:

error: extern declarations without an explicit ABI are deprecated
--> rust/doctests_kernel_generated.rs:3158:1
|
3158 | extern {
| ^^^^^^ help: explicitly specify the C ABI: `extern "C"`
|
= note: `-D missing-abi` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(missing_abi)]`

Thus clean it up.

Cc: <[email protected]> # Needed in 6.12.y and 6.13.y only (Rust is pinned in older LTSs).
Fixes: 7f8977a7fe6d ("rust: init: add `{pin_}chain` functions to `{Pin}Init<T, E>`")
Link: https://github.com/rust-lang/rust/pull/132397 [1]
Reviewed-by: Gary Guo <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Fiona Behrens <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Added 6.13.y to Cc: stable tag. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: init: update `stack_try_pin_init` examples

Change documentation imports to use `kernel::alloc::AllocError`,
because `KBox::new()` now returns that, instead of the `core`'s
`AllocError`.

Revie

rust: init: update `stack_try_pin_init` examples

Change documentation imports to use `kernel::alloc::AllocError`,
because `KBox::new()` now returns that, instead of the `core`'s
`AllocError`.

Reviewed-by: Danilo Krummrich <[email protected]>
Signed-off-by: Jimmy Ostler <[email protected]>
Link: https://lore.kernel.org/r/ec8badbe94c5e78f22315325a7f2ae96129d6a65.1734674670.git.jtostler1@gmail.com
[ Fixed formatting of imports (still unordered). Slightly reworded
commit. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: init: replace unwraps with question mark operators

Use `?` operator in the doctests. Since it is in the examples,
using unwraps can convey a wrong impression that unwrapping is
fine in general

rust: init: replace unwraps with question mark operators

Use `?` operator in the doctests. Since it is in the examples,
using unwraps can convey a wrong impression that unwrapping is
fine in general, thus this patch removes this unwrapping.

Suggested-by: Miguel Ojeda <[email protected]>
Link: https://lore.kernel.org/rust-for-linux/CANiq72nsK1D4NuQ1U7NqMWoYjXkqQSj4QuUEL98OmFbq022Z9A@mail.gmail.com/
Signed-off-by: Daniel Sedlak <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Reworded commit slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: use custom FFI integer types

Currently FFI integer types are defined in libcore. This commit creates
the `ffi` crate and asks bindgen to use that crate for FFI integer types
instead of `core::

rust: use custom FFI integer types

Currently FFI integer types are defined in libcore. This commit creates
the `ffi` crate and asks bindgen to use that crate for FFI integer types
instead of `core::ffi`.

This commit is preparatory and no type changes are made in this commit
yet.

Signed-off-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Added `rustdoc`, `rusttest` and KUnit tests support. Rebased on top of
`rust-next` (e.g. migrated more `core::ffi` cases). Reworded crate
docs slightly and formatted. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: alloc: remove extension of std's `Box`

Now that all existing `Box` users were moved to the kernel `Box` type,
remove the `BoxExt` extension and all other related extensions.

Reviewed-by: Alic

rust: alloc: remove extension of std's `Box`

Now that all existing `Box` users were moved to the kernel `Box` type,
remove the `BoxExt` extension and all other related extensions.

Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: treewide: switch to our kernel `Box` type

Now that we got the kernel `Box` type in place, convert all existing
`Box` users to make use of it.

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

rust: treewide: switch to our kernel `Box` type

Now that we got the kernel `Box` type in place, convert all existing
`Box` users to make use of it.

Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

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

rust: enable Clippy's `check-private-items`

In Rust 1.76.0, Clippy added the `check-private-items` lint configuration
option. When turned on (the default is off), it makes several lints
check privat

rust: enable Clippy's `check-private-items`

In Rust 1.76.0, Clippy added the `check-private-items` lint configuration
option. When turned on (the default is off), it makes several lints
check private items as well.

In our case, it affects two lints we have enabled [1]:
`missing_safety_doc` and `unnecessary_safety_doc`.

It also seems to affect the new `too_long_first_doc_paragraph` lint [2],
even though the documentation does not mention it.

Thus allow the few instances remaining we currently hit and enable
the lint.

Link: https://doc.rust-lang.org/nightly/clippy/lint_configuration.html#check-private-items [1]
Link: https://rust-lang.github.io/rust-clippy/master/index.html#/too_long_first_doc_paragraph [2]
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 ...

rust: init: remove unneeded `#[allow(clippy::disallowed_names)]`

These few cases, unlike others in the same file, did not need the `allow`.

Thus clean them up.

Reviewed-by: Alice Ryhl <aliceryhl@g

rust: init: remove unneeded `#[allow(clippy::disallowed_names)]`

These few cases, unlike others in the same file, did not need the `allow`.

Thus clean them up.

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

rust: enable `clippy::undocumented_unsafe_blocks` lint

Checking that we are not missing any `// SAFETY` comments in our `unsafe`
blocks is something we have wanted to do for a long time, as well as

rust: enable `clippy::undocumented_unsafe_blocks` lint

Checking that we are not missing any `// SAFETY` comments in our `unsafe`
blocks is something we have wanted to do for a long time, as well as
cleaning up the remaining cases that were not documented [1].

Back when Rust for Linux started, this was something that could have
been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0,
Clippy implemented the `undocumented_unsafe_blocks` lint [2].

Even though the lint has a few false positives, e.g. in some cases where
attributes appear between the comment and the `unsafe` block [3], there
are workarounds and the lint seems quite usable already.

Thus enable the lint now.

We still have a few cases to clean up, so just allow those for the moment
by writing a `TODO` comment -- some of those may be good candidates for
new contributors.

Link: https://github.com/Rust-for-Linux/linux/issues/351 [1]
Link: https://rust-lang.github.io/rust-clippy/master/#/undocumented_unsafe_blocks [2]
Link: https://github.com/rust-lang/rust-clippy/issues/13189 [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 ...

rust: init: add `assert_pinned` macro

Add a macro to statically check if a field of a struct is marked with
`#[pin]` ie that it is structurally pinned. This can be used when
`unsafe` code needs to r

rust: init: add `assert_pinned` macro

Add a macro to statically check if a field of a struct is marked with
`#[pin]` ie that it is structurally pinned. This can be used when
`unsafe` code needs to rely on fields being structurally pinned.

The macro has a special "inline" mode for the case where the type
depends on generic parameters from the surrounding scope.

Signed-off-by: Benno Lossin <[email protected]>
Co-developed-by: Alice Ryhl <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Replaced `compile_fail` with `ignore` and a TODO note. Removed
`pub` from example to clean `unreachable_pub` lint. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: init: add `write_[pin_]init` functions

Sometimes it is necessary to split allocation and initialization into
two steps. One such situation is when reusing existing allocations
obtained via `Bo

rust: init: add `write_[pin_]init` functions

Sometimes it is necessary to split allocation and initialization into
two steps. One such situation is when reusing existing allocations
obtained via `Box::drop_contents`. See [1] for an example.

In order to support this use case add `write_[pin_]init` functions to the
pin-init API. These functions operate on already allocated smart
pointers that wrap `MaybeUninit<T>`.

Link: https://lore.kernel.org/rust-for-linux/[email protected]/ [1]
Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Reviewed-by: Alice Ryhl <[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 ...

rust: Implement the smart pointer `InPlaceInit` for `Arc`

For pinned and unpinned initialization of structs, a trait named
`InPlaceInit` exists for uniform access. `Arc` did not implement
`InPlaceIn

rust: Implement the smart pointer `InPlaceInit` for `Arc`

For pinned and unpinned initialization of structs, a trait named
`InPlaceInit` exists for uniform access. `Arc` did not implement
`InPlaceInit` yet, although the functions already existed. The main
reason for that, was that the trait itself returned a `Pin<Self>`. The
`Arc` implementation of the kernel is already implicitly pinned.

To enable `Arc` to implement `InPlaceInit` and to have uniform access,
for in-place and pinned in-place initialization, an associated type is
introduced for `InPlaceInit`. The new implementation of `InPlaceInit`
for `Arc` sets `Arc` as the associated type. Older implementations use
an explicit `Pin<T>` as the associated type. The implemented methods for
`Arc` are mostly moved from a direct implementation on `Arc`. There
should be no user impact. The implementation for `ListArc` is omitted,
because it is not merged yet.

Link: https://github.com/Rust-for-Linux/linux/issues/1079
Signed-off-by: Alex Mantel <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Removed "Rusts" (Benno). - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: init: simplify from `map_err` to `inspect_err`

A new complexity lint, `manual_inspect` [1], has been introduced in
the upcoming Rust 1.81 (currently in nightly), which checks for uses of
`map*

rust: init: simplify from `map_err` to `inspect_err`

A new complexity lint, `manual_inspect` [1], has been introduced in
the upcoming Rust 1.81 (currently in nightly), which checks for uses of
`map*` which return the original item:

error:
--> rust/kernel/init.rs:846:23
|
846 | (self.1)(val).map_err(|e| {
| ^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#manual_inspect
= note: `-D clippy::manual-inspect` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::manual_inspect)]`
help: try
|
846 ~ (self.1)(val).inspect_err(|e| {
847 | // SAFETY: `slot` was initialized above.
848 ~ unsafe { core::ptr::drop_in_place(slot) };
|

Thus clean them up.

Link: https://rust-lang.github.io/rust-clippy/master/index.html#/manual_inspect [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 ...

rust: remove unneeded `kernel::prelude` imports from doctests

Rust doctests implicitly include `kernel::prelude::*`.

Removes explicit `kernel::prelude` imports from doctests.

Suggested-by: Miguel

rust: remove unneeded `kernel::prelude` imports from doctests

Rust doctests implicitly include `kernel::prelude::*`.

Removes explicit `kernel::prelude` imports from doctests.

Suggested-by: Miguel Ojeda <[email protected]>
Link: https://github.com/Rust-for-Linux/linux/issues/1064
Signed-off-by: Nell Shamrell-Harrington <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Add it back for `module_phy_driver`'s example since it is within a `mod`,
and thus it cannot be removed. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: kernel: remove usage of `allocator_api` unstable feature

With the adoption of `BoxExt` and `VecExt`, we don't need the functions
provided by this feature (namely the methods prefixed with `try

rust: kernel: remove usage of `allocator_api` unstable feature

With the adoption of `BoxExt` and `VecExt`, we don't need the functions
provided by this feature (namely the methods prefixed with `try_` and
different allocator per collection instance).

We do need `AllocError`, but we define our own as it is a trivial empty
struct.

Reviewed-by: Benno Lossin <[email protected]>
Signed-off-by: Wedson Almeida Filho <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: init: update `init` module to take allocation flags

This is the last component in the conversion for allocators to take
allocation flags as parameters.

Reviewed-by: Benno Lossin <benno.lossin

rust: init: update `init` module to take allocation flags

This is the last component in the conversion for allocators to take
allocation flags as parameters.

Reviewed-by: Benno Lossin <[email protected]>
Signed-off-by: Wedson Almeida Filho <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: sync: update `Arc` and `UniqueArc` to take allocation flags

We also remove the `try_` prefix to align with how `Box` and `Vec` are
providing methods now.

`init` is temporarily updated with us

rust: sync: update `Arc` and `UniqueArc` to take allocation flags

We also remove the `try_` prefix to align with how `Box` and `Vec` are
providing methods now.

`init` is temporarily updated with uses of GFP_KERNEL. These will be
updated in a subsequent patch to take flags as well.

Reviewed-by: Benno Lossin <[email protected]>
Signed-off-by: Wedson Almeida Filho <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...