On Thu, Apr 20, 2017 at 04:24:53PM +0200, Jiri Pirko wrote: > Thu, Apr 20, 2017 at 04:18:50PM CEST, j...@mojatatu.com wrote: > >On 17-04-20 09:59 AM, Jiri Pirko wrote: > >> Thu, Apr 20, 2017 at 03:06:21PM CEST, j...@mojatatu.com wrote: > >> > From: Jamal Hadi Salim <j...@mojatatu.com>
... > >> > + if (tcaa[TCAA_ACT_FLAGS]) > >> > + act_flags = nla_get_u32(tcaa[TCAA_ACT_FLAGS]); > >> > >> I still believe this is wrong. Should be a separate attr per flag. > >> For user experience breakage reasons: > >> 2 kernels should not behave differently on the exact same value passed > >> from userspace: > >> User passes 0x2. Now the kernel will ignore the set bit, the next kernel > >> will recognize it as a valid flag and do something. > >> Please let the discussion reach a consensus before pushing this again. > >> > >> > > > >Jiri - I dont agree. There is no such breakage. Refer to my previous > >email. Lets just move on. > > Anyone else has opinion on this? At the risk of jumping into a hornets nest, yes, I have an opinion: * A agree with Jiri that a separate attribute per flag seems to be the cleanest option, however; * I think it would be reasonable from a UABI PoV to permit currently unused bits of TCAA_ACT_FLAGS to be re-uses so long as the kernel checks that they are zero until they are designated to have some use. I believe this implies that the default value for any future uses of these bits would be zero. Jamal, I am confused about why are you so concerned about the space consumed by this attribute, it's per-message, right? Is it the bigger picture you are worried about - a similar per-entry flag at some point in the future?
