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

[Theodore Ts'o <tytso@mit.edu>]

On Thu, Aug 03, 2017 at 06:16:44PM -0700, Andy Lutomirski wrote:
> Maybe we could pull something off where big new features hide behind a
> named feature gate for a while.  That feature gate can only be enabled
> under some circumstances that make it very hard to mistake it for true
> stability.  (For example, maybe you *can't* enable feature gates on a
> final kernel unless you manually patch something.)

I think the problem you've pointed out is a real and vexing one, and
it's good we talk about possible solution. 

The challenge with using a feature gate is that the examples you gave
weren't the simply, obvious cases of a new syscall, but flags to a
system call (O_TMPFILE) or a new socket type (e.g., for RDMA).  So
that implies that adding a feature gate is going to requre making code
changes to enforce the ability turn off the feature.  Even if it's
done using CONFIG_* #ifdefs and KConfig options, it's going to require
more effort than cc'ing the patch to linux-api@vger.kernel.org.

And if the problem is that aren't bothering to remember to cc
linux-api@, I'm not sure it's realistic to think they will implement a
feature gate.

Furthermore, problems with an API design or implementation tend to get
noticed either (a) when someone else does a code audit and tries to
define exactly what the semantics will be for the new flag or syscall
or socket type, or (b) when someone tries using it and discovers
problems (usually not in the common path, since presumably the
developer tested that bit of it, but in the error handling).  The
feature gate won't necessarily help with (a), except that it gives
people a bit more time to notice that the new feature went in, and it
probably actively makes (b) worse, since if it is under a feature
gate, fewer people are likely to experiment with the new feature.

One way that we could try to make things better is by having some kind
of semi-automated system which monitors changes in include/uapi/*.h in
linux-next.  Unfortunately there will be a lot of false negatives, so
it's going to require a human to figure out which of the changes
represent new/changed API's, and which are just cleanups /
rearragements.  (We could try to see if we could train a Machine
Learning model --- but even if we can make a some nueral nets play Go,
I'm personally dubious this is something that ML would be successful
at.  I might be pleasantly surprised, though, if someone wanted to
give it a try.  :-)

				- Ted