On Wed, 2019-09-11 at 12:20 -0700, James Prestwood wrote: > I see what your saying, but theses kind of state changes are all over > the place in other APIs, and undocumented: One example is > SCAN_FLAG_FLUSH clearing out the scanning state for all other > processes. Scanning always changes scan list state? > I'm sure I could find more. If we documented this attribute > and behavior I don't see an issue. But I'm sure you could actually find an example :-) That doesn't really mean it's the *right* thing to do though, IMHO. Also, who says that this is the only thing? Next up, somebody wants to randomize the MTU? Ok, probably not, but you could pick a random other rtnetlink attribute and have nl80211 set it. Where do we stop? Thinking this to the extreme - why not add an rtnetlink message interpreter into this code? ;-) Sure, none of that is really seriously likely to happen, but I'm really not convinced we (more or less arbitrarily) need many ways of doing the same thing in the kernel. Either way, regardless of that discussion, I think it'd be good if you could repost the patches for just the "quick win" that we can all agree on, and then we can get those reviewed and into the tree before we need to continue this discussion; after all, while we're discussing saving about 3 milliseconds, you're still wasting around 280 :-) (and the easy one can be done without affecting the other, just need to reorder the patches and split them a bit differently) johannes
