Re: [PATCH v9] rust: kernel: add support for bits/genmask macros

[Danilo Krummrich]

On Wed Jul 16, 2025 at 9:44 PM CEST, Daniel Almeida wrote:
>
>
>> On 16 Jul 2025, at 16:32, Danilo Krummrich <dakr@xxxxxxxxxx> wrote:
>> 
>> On Wed Jul 16, 2025 at 9:11 PM CEST, Daniel Almeida wrote:
>>> Let’s transfer this discussion to this patch.
>>> 
>>>> I also quickly tried genmask and I have a few questions:
>>>> 
>>>> (1) Why does genmask not use a const generic? I think this makes it more
>>>>     obvious that it's only intended to be used from const context.
>>> 
>>> I guess none of us thought about it, since the current version also works.
>> 
>> I think using a const generic would be a bit better for the mentioned reason.
>
> Btw, how does monomorphization work here? Would we have to codegen all the
> versions? Also, I don't think that you can take a range as a const generic
> argument, i.e., I don't recall ever seeing this syntax:
>
> genmask_u64::<0..=63>();

Ah, of course, it's RangeInclusive, just scratch the const generic proposal. :)

>>>> (2) Why is there no build_assert() when the range exceeds the number of bits
>>>>     of the target type? I would expect genmask_u64(0..100) to fail.
>>> 
>>> Doesn’t it?
>>> 
>>> There is a build_assert in the underlying bit implementation. It was redundant
>>> to have it both in bit_* and in genmask, because genmask calls bit().
>>> 
>>> In your example, bit_u64(100) hits that assert, and so it shouldn't compile.
>> 
>> Indeed, and it also works, except from doc-tests for some reason, which is what
>> I tried real quick. :)
>> 
>
> Wait, this was a bit confusing :)
> You’re confirming that it doesn’t compile, correct?

Yes, except for in doc-tests for some reason.

>> I feel like usize would be a better fit, but not a strong opinion.
>
> I guess this is the same problem as u64: drivers will usually have either
> i32s/u32s and this would require a cast.

I don't understand this argument? We usualy use usize for such things, no?

>
> — Daniel