On Fri, Oct 27, 2023 at 2:46 PM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
I'm talking about a patch where you are changing the existing user/kernel api by filtering out values that you previously accepted. And it was done in a patch saying "this might break userspace", and guess what, it did!
So why not revert it as obviously you all anticipated that this might happen?
Because it's a useful patch, and while I mentioned the possibility of a regression, I definitely didn't expect it to happen.
And I still think that the Android case doesn't count, because it's just a completely different environment. What can happen on Android may not happen on non-Android and vice versa. Why should I revert a useful patch, because it causes a regression in a downstream kernel, because of an Android only patch?
The "internal" patch from Android was just using the upper values of the fuse api because they didn't want to conflict with the upstream values before their code was accepted (and it was submitted already, but not accepted.)
So how do you want developers to work on changes before they are accepted with this user/kernel numbering scheme that you have? You just broke anyone who was using a not-accepted-in-the-tree value, right?
Again, upstream and downstream. There's a reason why some companies have upstream first policies: because it's less painful in the long run. Android having decided to go ahead and add that patch is not my problem, and I really really don't want to care.
Having said all that, if there's a regression that someone reports for upstream flags (even on a vendor kernel), I'll just revert the patch right away.
Thanks, Miklos