Re: [PATCH net-next 2/7] net: nexthop: Add NHA_OP_FLAGS

[Petr Machata <petrm@nvidia.com>]

Jakub Kicinski <kuba@kernel.org> writes:

> On Wed, 28 Feb 2024 06:48:59 -0800 Jakub Kicinski wrote:
>> > 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.