Message-Id: <DG0A8B4DUBDB.2NT25Q8SZOHT7@nvidia.com>
Date: Wed, 28 Jan 2026 23:12:27 +0900
From: "Alexandre Courbot" <acourbot@...dia.com>
To: "Yury Norov" <ynorov@...dia.com>
Cc: "Joel Fernandes" <joelagnelf@...dia.com>, "Miguel Ojeda"
 <ojeda@...nel.org>, "Boqun Feng" <boqun.feng@...il.com>, "Gary Guo"
 <gary@...yguo.net>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, "Benno Lossin" <lossin@...nel.org>, "Andreas
 Hindborg" <a.hindborg@...nel.org>, "Alice Ryhl" <aliceryhl@...gle.com>,
 "Trevor Gross" <tmgross@...ch.edu>, "Danilo Krummrich" <dakr@...nel.org>,
 "Yury Norov" <yury.norov@...il.com>, "John Hubbard" <jhubbard@...dia.com>,
 "Alistair Popple" <apopple@...dia.com>, "Timur Tabi" <ttabi@...dia.com>,
 "Edwin Peer" <epeer@...dia.com>, "Eliot Courtney" <ecourtney@...dia.com>,
 "Daniel Almeida" <daniel.almeida@...labora.com>, "Dirk Behme"
 <dirk.behme@...bosch.com>, "Steven Price" <steven.price@....com>,
 <rust-for-linux@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/6] rust: add `bitfield!` macro

On Wed Jan 28, 2026 at 2:27 PM JST, Yury Norov wrote:
<snip>
>> >> The user simply learns not to use reserved words, and the compiler enforces
>> >> this clearly. The same applies here.
>> >
>> > Most likely he will learn not to use this API at all. The worst thing about
>> > those 'reserved' words is that the set of them is not definite and will
>> > constantly grow.
>> >
>> > I'm trying to say that this approach is not scalable. If a random client
>> > gives name 'invert' to one of his fields, and you'll need to implement a
>> > method inverting bits, what are you going to do?
>> 
>> Bitfields are limited to a _get, a _set, and an _update methods (and
>> possibly try_ variants for the last two). If an `invert` method needs to
>> be implemented, it can be done on top of _update which takes a closure.
>> So I am pretty confident we won't need to extend the API beyond these
>> (famous last words).
>  
> Not sure I understand this. You already have into(), shr(), shl() and
> others. By the way, maybe again follow C++ style, like:
>         
>         my_bitfield.shr         // field
>         my_bitfield.shr()       // method

The confusion comes from the fact that `shr` and pals are methods of
`Bounded`, not the bitfield structure. I.e. you call them on the field
that you obtained using the getter method - they are not part of the
bitfield interface itself which is only concerned with 3 basic
operations: get a field, set a field, update a field with a closure.

>
>> >> > Again, this all is relevant for a basic generic data structure. If we
>> >> > consider it a supporting layer for the registers, everything is totally
>> >> > fine. In that case, we should just give it a more specific name, and
>> >> > probably place in an different directory, closer to IO APIs.
>> >> 
>> >> The Bitfield macro is very much required for non-register use cases too.
>> >
>> > Then let's implement it better. Can you comment why the suggested API
>> > doesn't work for you?
>> >
>> >         color.set(blue, 10);
>> >         color.get(blue);
>> >
>> > I think it should solve the problem with name clashing.
>> 
>> That syntax cannot be implemented as it is written. What type is `blue` here?
>
> 'blue' has no type because it is not a variable but keyword. We do
> such things in C all the time:
>
>         DEFINE_FREE(kfree, void *, if (_T) kfree(_T))
>                     ^^^^^
>                     keyword that becomes a part of cleanup function name
>
> And in another email I seemingly do similar thing for python_init!()
> macro in rust to pick the right constructor.

Yup, and we could do the same in Rust with a macro, but your example
above was not macro code (macros are always ending with a `!`).

>
>> The closest we could get would be a macro, that would look like
>> 
>>     bitfield_set!(color, blue, 10);
>> 
>> And beyond the scenes it would call some more intricate (and unsightly)
>> machinery. I'd rather define the constraints clearly for users - they
>> are not so drastic.
>  
> But that would not be chainable, I guess. I recall, Joel said it's an
> important feature for some reason.

We could make the macros return the modified bitfield, which would make
them chainable. And the bitfield-englobing macro you proposed in your
other email could also reduce the need to do so anyway.

>
>> > Can you share more about the other potential users?
>> 
>> I know Joel is using bitfield for page table structures, but there are
>> of course many others. Basically any structure with fields defined as a
>> subset of its bits is a candidate. Registers just happen to be bitfields
>> with extra properties for I/O.
>
> OK. Can I take a look at how bitfields are used there?

Check out these patches:

https://lore.kernel.org/all/20260120204303.3229303-10-joelagnelf@nvidia.com/
https://lore.kernel.org/all/20260120204303.3229303-12-joelagnelf@nvidia.com/
https://lore.kernel.org/all/20260120204303.3229303-13-joelagnelf@nvidia.com/

But be aware that they use the `bitfield!` macro of nova-core, this one
doesn't use `Bounded` yet.

Powered by blists - more mailing lists