Benno Lossin
2025-Jun-03 22:53 UTC
[PATCH v4 04/20] rust: add new `num` module with useful integer operations
On Mon Jun 2, 2025 at 11:39 AM CEST, Danilo Krummrich wrote:> On Thu, May 29, 2025 at 09:27:33AM +0200, Benno Lossin wrote: >> That's also fair, but we lose the constness of `next_multiple_of`, so >> you can't use `align_up` in a const function. That might confuse people >> and then they write their own const helper function... I'd prefer we use >> all functions that are available in the stdlib. > > Considering that, what's the suggestion for this trait? > > I don't think we should have a trait with align_down() and fls() only and > otherwise use next_multiple_of(), i.e. mix things up.Agreed.> I think we should either align with the Rust nomenclature - whatever this means > for fls() - or implement the trait with all three methods.The longterm perspective would be to choose the Rust one. But I'd also understand if people want the kernel's own terms used. Still I prefer the Rust ones :) --- Cheers, Benno
Alexandre Courbot
2025-Jun-03 23:54 UTC
[PATCH v4 04/20] rust: add new `num` module with useful integer operations
On Wed Jun 4, 2025 at 7:53 AM JST, Benno Lossin wrote:> On Mon Jun 2, 2025 at 11:39 AM CEST, Danilo Krummrich wrote: >> On Thu, May 29, 2025 at 09:27:33AM +0200, Benno Lossin wrote: >>> That's also fair, but we lose the constness of `next_multiple_of`, so >>> you can't use `align_up` in a const function. That might confuse people >>> and then they write their own const helper function... I'd prefer we use >>> all functions that are available in the stdlib. >> >> Considering that, what's the suggestion for this trait? >> >> I don't think we should have a trait with align_down() and fls() only and >> otherwise use next_multiple_of(), i.e. mix things up. > > Agreed. > >> I think we should either align with the Rust nomenclature - whatever this means >> for fls() - or implement the trait with all three methods. > > The longterm perspective would be to choose the Rust one. But I'd also > understand if people want the kernel's own terms used. Still I prefer > the Rust ones :)My understanding is that so far we have tried to match the names of C counterparts as much as possible when reimplementing stuff. I don't think this particular module warrants an exception, which could cause confusion to folks coming from the C part of the kernel.