On Fri, 24 Jul 2026 09:39:54 -0700 Bobby Eshleman wrote: > > BTW did you add both min and max checks? Cause the only risk with using > > a dummy value would be that the policy will be rendered inline, and > > inline policy is u16 so 64k wouldn't fit. But your sample above has a > > max of u32_max which forces the out-of-line policy, which is what we > > want. > > Yep, u32_max: > > + name: rx-page-size > ... > + checks: > + min: page-size > + max: u32-max > > Sorry, probably should have just sent the whole patch instead of > replying hunk-by-hunk.
Ack, LG, just double checking. > BTW, how expressive do we want these policies? For example, would > absorbing the power_of_2 check into a policy be valid in the future? or > is that too bespoke? Power-of-2 could be useful (it's implicitly one bit set, which is also potentially useful for validating one-hot flags). The trickiness is combining power-of-2 and the min check :S We have one validation per field. I was wondering if we would be better off defining the field as a shift instead, then we only have to check min. But I thought that it'd be a little unusual for uAPI and possibly maybe one day we will want the non-power of 2? So I figured checking min using the existing facilities and open coding power of two check is good enough for now.
