Jakub Kicinski [off-list ref] writes:

On Wed, 28 Feb 2024 06:48:59 -0800 Jakub Kicinski wrote:

quoted

quoted

But also I don't know what will be useful in the
future. It would be silly to have to add another flags attribute as
bitfield because this time we actually care about toggling single bits
of an object.  

IDK how you can do RMW on operation flags, that only makes sense if
you're modifying something. Besides you're not using BITFIELD right,
you're ignoring the mask completely now.

Let me rephrase this a bit since I've had my coffee now :)
BITFILED is designed to do:

	object->flags = object->flags & ~bf->mask | bf->flags;

since there's no object, there's nothing to & the mask with.
Plus if we do have some object flags at some point, chances 
are we'd want the uAPI flags to mirror the recorded object flags
so that we don't have to translate bit positions, so new attr
will be cleaner.

That's just in the way of clarifying my thinking, your call..

Oh, I see, it wouldn't be useful as an attribute in isolation, and if we
ever introduce flags field for the NH objects, we would want a separate
attribute for it anyway. So whatever new uses the OP_FLAGS attribute
would be put to, we know we won't need the mask.

Um, so as I said, I mostly figured let's use bitfield because of the
validation. I really like how it's all part of the policy and there's no
explicit checking code. So I'd keep it as it is.