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

Andy Lutomirski luto at kernel.org
Tue Aug 15 16:11:31 UTC 2017


On Mon, Aug 14, 2017 at 5:54 PM, Linus Torvalds
<torvalds at linux-foundation.org> wrote:
> On Mon, Aug 14, 2017 at 4:23 PM, Andy Lutomirski <luto at kernel.org> wrote:
>>
>> 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?
>
> Honestly, I can't think of a case where that would actually have been an issue.
>
> Make a config option out of it, and mark it expert, and maybe that would do it.

That seems optimistic to me.

>
> But realistically, that just doesn't make any sense in reality -
> because in reality, user programs get written not on top of the
> development kernel, but on vendor kernels.

Plenty of user programs get written against development kernels.
iproute2 is a prime example.  But IIRC the reason that RDMA disaster
didn't get reverted is that people thought that user programs using it
existing something like one week after the stable kernel containing
the feature showed up.

>
> So the scenario you describe simply never happens.
>
> The _reverse_ scenario does happen: vendors who do their own kernel
> patches that introduce something their customers need, and people
> start depending on those semantics.
>
> Android may be the case where that happens today, but it's not the
> only case. We've merged code that was in use by various Linux distro
> people and where there already was an active user base of the new ABI.
>
> So I think your issue is pretty much theoretical, and _would_ be easy
> to fix with some kind of "this option is only enabled for rc kernels,
> and gets disabled on release", but such an option just doesn't make
> sense because that's not how development actually happens.

But maybe it would be a good thing if more development happened that
way.  If nothing else, we'd get lots more testing :)

>
>                Linus


More information about the Ksummit-discuss mailing list