Preface: considered CCing Linus here, as it's quite possible that I'm wrong, as every situation is somewhat different. If anybody disagrees with what I bring up below to hopefully clarify things thus please do me a favor an CC Linus so he can clarify things. Ohh, and sorry for being a PITA. I hate that, but when it comes to regressions disagreements often happen, as all those discussions linked at the end of https://docs.kernel.org/process/handling-regressions.html illustrate. On 22.11.23 12:58, Borislav Petkov wrote: > On Wed, Nov 22, 2023 at 10:15:42AM +0100, Linux regression tracking (Thorsten Leemhuis) wrote: >> [1] unless you fiddle with things obviously internal; not sure if this >> case would qualify for him, but somehow I doubt it -- but I might be >> wrong there. > > Well, think about it - by that logic, if CONFIG_* items are an ABI, we > will never ever be able to change any of them. [...] Can't follow your logic (or the one from Lukas in the other reply), as what's an ABI (or an API) is afaik not the important factor when it comes to the "no regressions" rule: you can change things (including ABIs or APIs) all you want, as long as nothing breaks. To quote Linus from https://lore.kernel.org/all/CAHk-=wiVi7mSrsMP=fLXQrXK_UimybW=ziLOwSzFTtoXUacWVQ@xxxxxxxxxxxxxx/ ``` The rules about regressions have never been about any kind of documented behavior, or where the code lives. The rules about regressions are always about "breaks user workflow". The other side of the coin is that people who talk about "API stability" are entirely wrong. API's don't matter either. You can make any changes to an API you like - as long as nobody notices. Again, the regression rule is not about documentation, not about API's, and not about the phase of the moon. It's entirely about "we caused problems for user space that used to work". ``` >> BTW: I see that this could help preventing problems like the current one >> to happen in the far future. But how would that help the current >> situation (e.g. users that have an old dracut and updated the kernel >> without updating dracut)? > Update dracut too? To quote Linus again, this time from https://lore.kernel.org/lkml/CA+55aFxW7NMAMvYhkvz1UPbUTUJewRt6Yb51QAx5RtrWOwjebg@xxxxxxxxxxxxxx/ ``` People should basically always feel like they can update their kernel and simply not have to worry about it. I refuse to introduce "you can only update the kernel if you also update that other program" kind of limitations. If the kernel used to work for you, the rule is that it continues to work for you. There have been exceptions, but they are few and far between, [...] But if something actually breaks, then the change must get fixed or reverted. And it gets fixed in the *kernel*. Not by saying "well, fix your user space then". ``` Are those quotes fitting to the situation at hand? Not totally sure. Initramfs generators might be special and we have done exceptions for them in the past if no other solution could be found to prevent a regression[1]. We'd need Linus to clarify. Ciao, Thorsten [1] maybe it's a naive idea, but can't we just avoid the problem at hand by adding CONFIG_MICROCODE_AMD and CONFIG_MICROCODE_INTEL back as a hidden config stub and remove those in ~3 years? Yeah, ugly, but we have done things way more ugly than that to prevent regressions.
