On Fri, Oct 27, 2023 at 03:03:28PM +0200, Miklos Szeredi wrote: > 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. But it did :( > 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? It's not all that different of an environment, they use a stock kernel, you can boot an android device just fine for many years without any changes. I would argue there are less changes in an android kernel than an "enterprise" linux distro kernel these days by far :) > > 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. I think you rejected Android's changes, so what were they supposed to do? Or someone did, I can't remember when it was submitted, but i do remember seeing the patches flow by on some list... > 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. So because Android userspace is sending a flag value that is not in the upstream table, this breakage is ok? Or do you mean something else, I'm getting confused. thanks, greg k-h
