Re: [PATCH] rust: impl_flags: add method to return underlying integer

[Andreas Hindborg <a.hindborg@kernel.org>]

"Gary Guo" <gary@garyguo.net> writes:

> On 2026-02-14 08:02, Andreas Hindborg wrote:
>> Gary Guo <gary@garyguo.net> writes:
>>
>>> On 2026-02-12 16:02, Andreas Hindborg wrote:
>>>> Add a method to return the underlying integer used for flags. This is
>>>> useful when using the flags with C APIs.
>>>>
>>>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>>>
>>> I am not sure if we want to actually expose the underlying representation
>>> for all flags. It should be something up to the caller of `impl_flags` to
>>> decide.
>>>
>>> Would it make sense to add visibility the wrapped raw type so that you
>>> can do
>>>
>>> impl_flags! {
>>>     pub struct Foo(pub u32);
>>>     ...
>>> }
>>>
>>> to make the inner accessible?
>>
>> I don't see how that is better?
>>
>>                 bindings::blk_mq_tag_set {
>>                     ...
>>                     flags: flags.into_inner(),
>>                     ...
>>                 }
>>
>> vs
>>
>>                 bindings::blk_mq_tag_set {
>>                     ...
>>                     flags: flags.0,
>>                     ...
>>                 }
>>
>>
>> I would prefer the first one.
>
> How about we expand `($inner_vis:vis $ty:ty)` to be
>
>     $inner_vis fn into_inner(self) -> $ty {}
>
> ? This way unless you explicitly put `pub` there, users outside the module
> cannot query the bit pattern.

Sounds good. We might get some dead code warnings maybe?

>
>>
>> We are going to need to be able to pass these flags into C APIs. I feel
>> like adding a method to do this is the best way to go about this. We can
>> call it something else if that communicates the purpose better.
>
> I think `bitflags` crate call this `bits`, which I think is indeed
> slightly better than `into_inner`.

Sounds good.


Best regards,
Andreas Hindborg