OK, here I guess I see what you mean. You're saying if ethtool were to
send a value/mask of "0..0100/0..0111" you wouldn't know what to do with
BIT(4) as long as the kernel knows about that bit?

I guess the difference now is depending on the operation. NLA_BITFIELD32
is sort of built on the assumption of having a "toggle" operation. If
you want to have a "set to" operation, then you don't really need the
selector/mask at all, just the value.

I don't think it is as simple as this. User space has a few different
things it wants to pass to the kernel:

I want to set this bit to 0
I want to set this bit to 1
I don't want to change this bit
In my world view, this bit is unused

The kernel has had a long history of trouble with flag bits in system
calls. It has not validated that unused bits are clear. Meaning when
you actually want to make use of the unused bits you cannot because
userspace has been passing random values in them since day 1.

We need a design which is clear to everybody which bits are unused and
should be validated as being unused and an error returned if an unused
bit is actually used. A value and a mask is not sufficient for
this. We need the length in bits.

      Andrew