Nouveau - Jun 2025 - [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

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.