On Wed Jun 4, 2025 at 1:54 AM CEST, Alexandre Courbot wrote: > 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.
There are instances of both, sometimes we have taken the Rust names, sometimes we have taken the C names. While wrapping a C API, we have mostly stuck to the C names, since that's what people are used to. But for more "core" code that's used by everyone, we often have used the Rust names. For example for the reference counting stuff, we have not used the `_get` and `_put` names, as that is done very different in Rust with `Drop`. --- Cheers, Benno
