Re: [Ksummit-discuss] [MAINTAINER TOPIC] ABI feature gates?

[Andy Lutomirski <luto@kernel.org>]

On Mon, Aug 14, 2017 at 11:40 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Aug 14, 2017 at 11:34 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> If you worry about how good and stable your ABI is, and aren't willing
>> to support that ABI forever, don't send the patch. Seriously. Just
>> don't.
>>
>> This whole discussion is pointless.
>
> To clarify, and to strengthen the point: the regression has always
> been about actual breakage. You can change semantics all you want, if
> nobody ever notices.
>
> But if somebody does notice, and something breaks, it gets fixed.
>
> That's the rule. No exceptions. If you aren't willing to fix the bugs
> you introduce, you shouldn't be working on the kernel.

What I was trying to get at with this thread was: is there a way that
we can enable a new feature for testing in a way that it *can't* get
used by real programs that expect stability?  There are certainly
nasty solutions.  For example, cgroup v2 cpu controller support has
been available as an out-of-tree patch for many cycles.  It's finally
being hashed out in a way that's incompatible with programs that
target that patch, but no one is going say "screw you, 4.14 broke my
setup" because that setup didn't work on any earlier kernel either.

I'm wondering if we can maybe make this more systematic and less
nasty.  For example, what if we could have a way to enable features
such that they work in -rc kernels (with big warnings!) but do *not*
work in released kernels?  Then people who want to develop against
them would have to explicitly run -rc kernels, which would make it
obvious that nothing's stable and might even get more -rc testers to
boot.

--Andy