On Fri, Apr 21, 2017 at 02:11:00PM -0400, Jamal Hadi Salim wrote: > On 17-04-21 12:12 PM, David Miller wrote: > > >Yes for existing attributes we are stuck in the mud because of how > >we've handled things in the past. I'm not saying we should change > >behavior for existing attributes. > > > >I'm talking about any newly added attribute from here on out, and > >that we need to require checks for them. > > > > Please bear with me. I want to make sure to get this right. > > Lets say I updated the kernel today to reject transactions with > bits it didnt understand. Lets call this "old kernel". A tc that > understands/sets these bits and nothing else. Call it "old tc". > 3 months later: > I add one more bit setting to introduce a new feature in a new > kernel version. Lets call this new "kernel". I update to > understand new bits. Call it "new tc". > > The possibilities: > a) old tc + old kernel combo. No problem > b) new tc + new kernel combo. No problem. > c) old tc + new kernel combo. No problem. > d) new tc + old kernel. Rejection. > > For #d if i have a smart tc it would retry with a new combination > which restores its behavior to old tc level. Of course this means > apps would have to be rewritten going forward to understand these > mechanics. > Alternative is to request for capabilities first then doing a > lowest common denominator request. > But even that is a lot more code and crossing user/kernel twice.
>From my PoV, for #d user-space has to either get smart or fail. Creating new tc involved work in order to support the new feature. Part of that work would be a decision weather or not to provide compatibility for old kernel or to bail out gracefully. > There is a simpler approach that would work going forward. > How about letting the user choose their fate? Set something maybe > in the netlink header to tell the kernel "if you dont understand > something I am asking for - please ignore it and do what you can". > This would maintain current behavior but would force the user to > explicitly state so. > > cheers, > jamal >
