On Sun Mar 1, 2026 at 4:34 PM GMT, Andreas Hindborg wrote:
> "Gary Guo" <[email protected]> writes:
>
>> On Tue Feb 24, 2026 at 11:17 AM GMT, Andreas Hindborg wrote:
>>> Add a method to consume a `Box<T, A>` and return a `NonNull<T>`. This
>>> is a convenience wrapper around `Self::into_raw` for callers that need
>>> a `NonNull` pointer rather than a raw pointer.
>>>
>>> Signed-off-by: Andreas Hindborg <[email protected]>
>>> ---
>>>  rust/kernel/alloc/kbox.rs | 8 ++++++++
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/rust/kernel/alloc/kbox.rs b/rust/kernel/alloc/kbox.rs
>>> index 622b3529edfcb..e6efdd572aeea 100644
>>> --- a/rust/kernel/alloc/kbox.rs
>>> +++ b/rust/kernel/alloc/kbox.rs
>>> @@ -213,6 +213,14 @@ pub fn leak<'a>(b: Self) -> &'a mut T {
>>>          // which points to an initialized instance of `T`.
>>>          unsafe { &mut *Box::into_raw(b) }
>>>      }
>>> +
>>> +    /// Consumes the `Box<T,A>` and returns a `NonNull<T>`.
>>> +    ///
>>> +    /// Like [`Self::into_raw`], but returns a `NonNull`.
>>> +    pub fn into_nonnull(b: Self) -> NonNull<T> {
>>> +        // SAFETY: `KBox::into_raw` returns a valid pointer.
>>> +        unsafe { NonNull::new_unchecked(Self::into_raw(b)) }
>>> +    }
>>
>> Hi Andreas,
>>
>> It looks like this patch and many others in the series are missing 
>> `#[inline]`
>> for quite a few very simple functions. Could you go through the series and 
>> mark
>> small functions as such?
>
> Sure.
>
> Could you remind me why we need this directive? Would the compiler not
> be able to decide?

`#[inline]` is a hint to make it more likely for compilers to inline. Without
them, you're relying on compiler heurstics only. There're cases (especially with
abstractions) where the function may look complex as it contains lots of
function calls (so compiler heurstics avoid inlining them), but they're all
zero-cost abstractions so eventually things get optimized away.

For non-generic functions, there is additional issue where only very small
functions get automatically inlined, otherwise a single copy is generated at the
defining crate and compiler run on a dependant crate has no chance to even peek
what's in the function.

If you know a function should be inlined, it's better to just mark them as such,
so there're no surprises.

Best,
Gary

>
> I know we have an issue when we have call to C function in short
> functions, but not in the general case?
>
>
> Best regards,
> Andreas Hindborg

Reply via email to