On Fri, Oct 27, 2023 at 2:46 PM Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> 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
