rust/kernel/alloc/allocator.rs | 2 +- rust/kernel/alloc/kvec.rs | 10 +++++----- rust/kernel/alloc/layout.rs | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-)
This patch series makes various functions in the `alloc` crate const fn. Each patch corresponds to a different module within the same `alloc` crate. Onur Özkan (3): rust: make `allocator::aligned_size` a `const fn` rust: make `ArrayLayout::new_unchecked` a `const fn` rust: make `kvec::Vec` functions `const fn` rust/kernel/alloc/allocator.rs | 2 +- rust/kernel/alloc/kvec.rs | 10 +++++----- rust/kernel/alloc/layout.rs | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) -- 2.50.0
On 7/20/25 11:48 AM, Onur Özkan wrote: > rust: make `allocator::aligned_size` a `const fn` I dropped this patch, since it would conflict with [1]. > rust: make `ArrayLayout::new_unchecked` a `const fn` > rust: make `kvec::Vec` functions `const fn` Applied to alloc-next, thanks! [1] https://lore.kernel.org/all/20250731154919.4132-2-dakr@kernel.org/
On Sun, Jul 20, 2025 at 12:48:35PM +0300, Onur Özkan wrote: > This patch series makes various functions in the > `alloc` crate const fn. > > Each patch corresponds to a different module within > the same `alloc` crate. > > Onur Özkan (3): > rust: make `allocator::aligned_size` a `const fn` > rust: make `ArrayLayout::new_unchecked` a `const fn` > rust: make `kvec::Vec` functions `const fn` > > rust/kernel/alloc/allocator.rs | 2 +- > rust/kernel/alloc/kvec.rs | 10 +++++----- > rust/kernel/alloc/layout.rs | 2 +- > 3 files changed, 7 insertions(+), 7 deletions(-) > > -- > 2.50.0 Reviewed-by: Alice Ryhl <aliceryhl@google.com>
On Sun Jul 20, 2025 at 11:48 AM CEST, Onur Özkan wrote: > This patch series makes various functions in the > `alloc` crate const fn. > > Each patch corresponds to a different module within > the same `alloc` crate. > > Onur Özkan (3): > rust: make `allocator::aligned_size` a `const fn` > rust: make `ArrayLayout::new_unchecked` a `const fn` > rust: make `kvec::Vec` functions `const fn` > > rust/kernel/alloc/allocator.rs | 2 +- > rust/kernel/alloc/kvec.rs | 10 +++++----- > rust/kernel/alloc/layout.rs | 2 +- > 3 files changed, 7 insertions(+), 7 deletions(-) This looks sensible, any particular reason for why you need them const? For the entire series: Reviewed-by: Benno Lossin <lossin@kernel.org> --- Cheers, Benno
On Sun, 20 Jul 2025 16:43:49 +0200 "Benno Lossin" <lossin@kernel.org> wrote: > On Sun Jul 20, 2025 at 11:48 AM CEST, Onur Özkan wrote: > > This patch series makes various functions in the > > `alloc` crate const fn. > > > > Each patch corresponds to a different module within > > the same `alloc` crate. > > > > Onur Özkan (3): > > rust: make `allocator::aligned_size` a `const fn` > > rust: make `ArrayLayout::new_unchecked` a `const fn` > > rust: make `kvec::Vec` functions `const fn` > > > > rust/kernel/alloc/allocator.rs | 2 +- > > rust/kernel/alloc/kvec.rs | 10 +++++----- > > rust/kernel/alloc/layout.rs | 2 +- > > 3 files changed, 7 insertions(+), 7 deletions(-) > > This looks sensible, any particular reason for why you need them > const? > > For the entire series: > > Reviewed-by: Benno Lossin <lossin@kernel.org> > > --- > Cheers, > Benno Personally, I don't have a specific reason. I thought the change is harmless and might extend functionality for other people in the future. It could also (although less likely) help the compiler optimize things further. Regards, Onur
On Sun, Jul 20, 2025 at 5:17 PM Onur Özkan <work@onurozkan.dev> wrote: > > Personally, I don't have a specific reason. I thought the change is > harmless and might extend functionality for other people in the future. > It could also (although less likely) help the compiler optimize things > further. I think it is OK -- even if we promise they are `const` and we have to remove it in the future, it is fine, since there is no stable kernel API. So that flexibility is another advantage of no promises there. However, I am curious, in which cases it would help the compiler optimize? The compiler already has the information on whether it could actually be `const` and whether it can be evaluated at compile-time and so on -- do you mean it has an effect on heuristics like inlining or similar? Thanks! Cheers, Miguel
On Sun, 20 Jul 2025 17:42:43 +0200 Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > On Sun, Jul 20, 2025 at 5:17 PM Onur Özkan <work@onurozkan.dev> wrote: > > > > Personally, I don't have a specific reason. I thought the change is > > harmless and might extend functionality for other people in the > > future. It could also (although less likely) help the compiler > > optimize things further. > > I think it is OK -- even if we promise they are `const` and we have to > remove it in the future, it is fine, since there is no stable kernel > API. So that flexibility is another advantage of no promises there. > > However, I am curious, in which cases it would help the compiler > optimize? The compiler already has the information on whether it could > actually be `const` and whether it can be evaluated at compile-time > and so on -- do you mean it has an effect on heuristics like inlining > or similar? I thought it had effects similar to inlining, but after digging into the assembly output of a simple program (with and without `const` expressions) and reading some related discussions [1], it seems I was wrong about it, sorry. [1]: https://users.rust-lang.org/t/the-effects-of-const-fn/48303 Regards, Onur
On Mon, Jul 21, 2025 at 8:14 AM Onur Özkan <work@onurozkan.dev> wrote: > > I thought it had effects similar to inlining, but after digging into the > assembly output of a simple program (with and without `const` > expressions) and reading some related discussions [1], it seems I was > wrong about it, sorry. No worries at all, and thanks for taking a look into it! I think Danilo will take this eventually through `alloc`, but it sounds good to me. Cheers, Miguel
© 2016 - 2025 Red Hat, Inc.