Re: [PATCH] rust: alloc: allow different error types in `KBox::pin_slice`

["Benno Lossin" <lossin@kernel.org>]

On Sat Feb 14, 2026 at 3:56 PM CET, Danilo Krummrich wrote:
> On Sat Feb 14, 2026 at 3:40 PM CET, Benno Lossin wrote:
>> On Sat Feb 14, 2026 at 3:17 PM CET, Danilo Krummrich wrote:
>>> On Sat Feb 14, 2026 at 2:28 PM CET, Andreas Hindborg wrote:
>>>> @@ -333,24 +333,31 @@ pub fn pin(x: T, flags: Flags) -> Result<Pin<Box<T, A>>, AllocError>
>>>>      /// assert_eq!(s[3].d.lock().a, 20);
>>>>      /// # Ok::<(), Error>(())
>>>>      /// ```
>>>> -    pub fn pin_slice<Func, Item, E>(
>>>> +    pub fn pin_slice<Func, Item, E, E2>(
>>>>          mut init: Func,
>>>>          len: usize,
>>>>          flags: Flags,
>>>>      ) -> Result<Pin<Box<[T], A>>, E>
>>>>      where
>>>>          Func: FnMut(usize) -> Item,
>>>> -        Item: PinInit<T, E>,
>>>> -        E: From<AllocError>,
>>>
>>> I think we should keep this bound and just add:
>>
>> The `Into` trait bounds are the idiomatic ones for functions consuming
>> things. See https://doc.rust-lang.org/std/convert/trait.Into.html:
>>
>>     Prefer using Into over From when specifying trait bounds on a
>>     generic function to ensure that types that only implement Into can
>>     be used as well.
>
> Yeah, but isn't this only because of [1], which does not apply to the kernel
> because our minimum compiler version is 1.78 anyways?
>
> I.e. are there any cases where we can't implement From in the kernel and have to
> fall back to Into?

Hmm that's interesting. I'm not sure if that's the only reason. It would
be interesting to ask the Rust folks if there 1) is a different use-case
for `Into` today; and 2) if they could remove `Into`, would they? If the
answer to 2 is "yes", then we could think about doing that (or at least
document it for us).

Cheers,
Benno

>
> [1] https://doc.rust-lang.org/std/convert/trait.Into.html#implementing-into-for-conversions-to-external-types-in-old-versions-of-rust