Re: [PATCH 3/6] rust: add `bitfield!` macro

[Yury Norov <ynorov@nvidia.com>]

On Wed, Jan 28, 2026 at 11:12:27PM +0900, Alexandre Courbot wrote:
> On Wed Jan 28, 2026 at 2:27 PM JST, Yury Norov wrote:

 <snip>

> >> > 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 `!`).

color.set!(blue, 10) is equally good, if it helps.

If someone will point to the excessive use of macros, you're safe to
ignore it. This is the very basic fundamental type, and I believe that
it brings enough attention and expertise to make it safe.

> >> The closest we could get would be a macro, that would look like
> >> 
> >>     bitfield_set!(color, blue, 10);

Or maybe bitfield_set!(color.blue, 10), but the above looks more natural.
Is it possible to make it color.blue = 10 by any chance?

Again (and again) - usability and readability is a king, and I'm glad
we're moving toward the right direction.

> >> 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.