| 5657c3a9 | 08-Mar-2025 |
Benno Lossin <[email protected]> |
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 ...
|
| 9d29c682 | 08-Mar-2025 |
Benno Lossin <[email protected]> |
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 ...
|
| c27e705c | 20-Nov-2024 |
Alice Ryhl <[email protected]> |
rust: kernel: add improved version of `ForeignOwnable::borrow_mut`
Previously, the `ForeignOwnable` trait had a method called `borrow_mut`
that was intended to provide mutable access to the inner va
rust: kernel: add improved version of `ForeignOwnable::borrow_mut`
Previously, the `ForeignOwnable` trait had a method called `borrow_mut`
that was intended to provide mutable access to the inner value. However,
the method accidentally made it possible to change the address of the
object being modified, which usually isn't what we want. (And when we
want that, it can be done by calling `from_foreign` and `into_foreign`,
like how the old `borrow_mut` was implemented.)
In this patch, we introduce an alternate definition of `borrow_mut` that
solves the previous problem. Conceptually, given a pointer type `P` that
implements `ForeignOwnable`, the `borrow_mut` method gives you the same
kind of access as an `&mut P` would, except that it does not let you
change the pointer `P` itself.
This is analogous to how the existing `borrow` method provides the same
kind of access to the inner value as an `&P`.
Note that for types like `Arc`, having an `&mut Arc<T>` only gives you
immutable access to the inner `T`. This is because mutable references
assume exclusive access, but there might be other handles to the same
reference counted value, so the access isn't exclusive. The `Arc` type
implements this by making `borrow_mut` return the same type as `borrow`.
Signed-off-by: Alice Ryhl <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Reviewed-by: Martin Rodriguez Reboredo <[email protected]>
Reviewed-by: Andreas Hindborg <[email protected]>
Signed-off-by: Tamir Duberstein <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Updated to `crate::ffi::`. Reworded title slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| 14686571 | 20-Nov-2024 |
Tamir Duberstein <[email protected]> |
rust: kernel: change `ForeignOwnable` pointer to mut
It is slightly more convenient to operate on mut pointers, and this also
properly conveys the desired ownership semantics of the trait.
Reviewed
rust: kernel: change `ForeignOwnable` pointer to mut
It is slightly more convenient to operate on mut pointers, and this also
properly conveys the desired ownership semantics of the trait.
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Andreas Hindborg <[email protected]>
Signed-off-by: Tamir Duberstein <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Reworded title slightly. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| aa991a2a | 20-Nov-2024 |
Tamir Duberstein <[email protected]> |
rust: types: avoid `as` casts
Replace `as` casts with `cast{,_mut}` calls which are a bit safer.
In one instance, remove an unnecessary `as` cast without replacement.
Reviewed-by: Alice Ryhl <alic
rust: types: avoid `as` casts
Replace `as` casts with `cast{,_mut}` calls which are a bit safer.
In one instance, remove an unnecessary `as` cast without replacement.
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Andreas Hindborg <[email protected]>
Signed-off-by: Tamir Duberstein <[email protected]>
Acked-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| 392e34b6 | 04-Oct-2024 |
Danilo Krummrich <[email protected]> |
kbuild: rust: remove the `alloc` crate and `GlobalAlloc`
Now that we have our own `Allocator`, `Box` and `Vec` types we can remove
Rust's `alloc` crate and the `new_uninit` unstable feature.
Also r
kbuild: rust: remove the `alloc` crate and `GlobalAlloc`
Now that we have our own `Allocator`, `Box` and `Vec` types we can remove
Rust's `alloc` crate and the `new_uninit` unstable feature.
Also remove `Kmalloc`'s `GlobalAlloc` implementation -- we can't remove
this in a separate patch, since the `alloc` crate requires a
`#[global_allocator]` to set, that implements `GlobalAlloc`.
Signed-off-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| dd09538f | 04-Oct-2024 |
Danilo Krummrich <[email protected]> |
rust: alloc: implement `Cmalloc` in module allocator_test
So far the kernel's `Box` and `Vec` types can't be used by userspace
test cases, since all users of those types (e.g. `CString`) use kernel
rust: alloc: implement `Cmalloc` in module allocator_test
So far the kernel's `Box` and `Vec` types can't be used by userspace
test cases, since all users of those types (e.g. `CString`) use kernel
allocators for instantiation.
In order to allow userspace test cases to make use of such types as
well, implement the `Cmalloc` allocator within the allocator_test module
and type alias all kernel allocators to `Cmalloc`. The `Cmalloc`
allocator uses libc's `realloc()` function as allocator backend.
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]
[ Removed the temporary `allow(dead_code)` as discussed in the list and
fixed typo, added backticks. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| 93e60231 | 04-Oct-2024 |
Danilo Krummrich <[email protected]> |
rust: alloc: implement `collect` for `IntoIter`
Currently, we can't implement `FromIterator`. There are a couple of
issues with this trait in the kernel, namely:
- Rust's specialization feature i
rust: alloc: implement `collect` for `IntoIter`
Currently, we can't implement `FromIterator`. There are a couple of
issues with this trait in the kernel, namely:
- Rust's specialization feature is unstable. This prevents us to
optimize for the special case where `I::IntoIter` equals `Vec`'s
`IntoIter` type.
- We also can't use `I::IntoIter`'s type ID either to work around this,
since `FromIterator` doesn't require this type to be `'static`.
- `FromIterator::from_iter` does return `Self` instead of
`Result<Self, AllocError>`, hence we can't properly handle allocation
failures.
- Neither `Iterator::collect` nor `FromIterator::from_iter` can handle
additional allocation flags.
Instead, provide `IntoIter::collect`, such that we can at least convert
`IntoIter` into a `Vec` again.
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: Benno Lossin <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Added newline in documentation, changed case of section to be
consistent with an existing one, fixed typo. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| 1d1d223a | 04-Oct-2024 |
Danilo Krummrich <[email protected]> |
rust: alloc: implement `IntoIterator` for `Vec`
Implement `IntoIterator` for `Vec`, `Vec`'s `IntoIter` type, as well as
`Iterator` for `IntoIter`.
`Vec::into_iter` disassembles the `Vec` into its r
rust: alloc: implement `IntoIterator` for `Vec`
Implement `IntoIterator` for `Vec`, `Vec`'s `IntoIter` type, as well as
`Iterator` for `IntoIter`.
`Vec::into_iter` disassembles the `Vec` into its raw parts; additionally,
`IntoIter` keeps track of a separate pointer, which is incremented
correspondingly as the iterator advances, while the length, or the count
of elements, is decremented.
This also means that `IntoIter` takes the ownership of the backing
buffer and is responsible to drop the remaining elements and free the
backing buffer, if it's dropped.
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]
[ Fixed typos. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| 2aac4cd7 | 04-Oct-2024 |
Danilo Krummrich <[email protected]> |
rust: alloc: implement kernel `Vec` type
`Vec` provides a contiguous growable array type with contents allocated
with the kernel's allocators (e.g. `Kmalloc`, `Vmalloc` or `KVmalloc`).
In contrast
rust: alloc: implement kernel `Vec` type
`Vec` provides a contiguous growable array type with contents allocated
with the kernel's allocators (e.g. `Kmalloc`, `Vmalloc` or `KVmalloc`).
In contrast to Rust's stdlib `Vec` type, the kernel `Vec` type considers
the kernel's GFP flags for all appropriate functions, always reports
allocation failures through `Result<_, AllocError>` and remains
independent from unstable features.
[ This patch starts using a new unstable feature, `inline_const`, but
it was stabilized in Rust 1.79.0, i.e. the next version after the
minimum one, thus it will not be an issue. - Miguel ]
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]
[ Cleaned `rustdoc` unescaped backtick warning, added a couple more
backticks elsewhere, fixed typos, sorted `feature`s, rewrapped
documentation lines. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| 9e7bbfa1 | 04-Oct-2024 |
Benno Lossin <[email protected]> |
rust: alloc: introduce `ArrayLayout`
When allocating memory for arrays using allocators, the `Layout::array`
function is typically used. It returns a result, since the given size
might be too big. H
rust: alloc: introduce `ArrayLayout`
When allocating memory for arrays using allocators, the `Layout::array`
function is typically used. It returns a result, since the given size
might be too big. However, `Vec` and its iterators store their allocated
capacity and thus they already did check that the size is not too big.
The `ArrayLayout` type provides this exact behavior, as it can be
infallibly converted into a `Layout`. Instead of a `usize` capacity,
`Vec` and other similar array-storing types can use `ArrayLayout`
instead.
Reviewed-by: Gary Guo <[email protected]>
Signed-off-by: Benno Lossin <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Formatted a few comments. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|
| c8cfa8d0 | 04-Oct-2024 |
Danilo Krummrich <[email protected]> |
rust: alloc: implement kernel `Box`
`Box` provides the simplest way to allocate memory for a generic type
with one of the kernel's allocators, e.g. `Kmalloc`, `Vmalloc` or
`KVmalloc`.
In contrast t
rust: alloc: implement kernel `Box`
`Box` provides the simplest way to allocate memory for a generic type
with one of the kernel's allocators, e.g. `Kmalloc`, `Vmalloc` or
`KVmalloc`.
In contrast to Rust's `Box` type, the kernel `Box` type considers the
kernel's GFP flags for all appropriate functions, always reports
allocation failures through `Result<_, AllocError>` and remains
independent from unstable features.
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]
[ Added backticks, fixed typos. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>
show more ...
|