[Ksummit-discuss] [CORE TOPIC] Reviewing new API/ABI

[Greg KH]

On Tue, May 06, 2014 at 10:45:05AM -0700, Andy Lutomirski wrote:
> There doesn't currently seem to be any real process for reviewing new
> core APIs for sanity of design, appropriateness to solve the problem
> they're targetting, or correctness of implementation.  Some examples
> that come to mind recently:
> 
>  - A lot of people seem to think that O_TMPFILE is a terrible
> interface, despite the fact that the functionality it provides is very
> useful.  It was also rather badly broken until -rc8 or so.
> 
>  - The x86 32-bit vdso clock functions almost made it in with a
> questionable symbol version.
> 
>  - 3.15 is currently slated to include an unfortunate ABI glitch in
> the MIPS seccomp filter interface.  There's a patch.
> 
>  - There are some aspects of the keyring API that seem to me to be quite bad.
> 
>  - An impressive number of new APIs are missing -EINVAL returns if
> reserved parameters are set.
> 
> (I'm not trying to point a finger at anyone with these examples;
> they're just things that I was involved in to some extent.)
> 
> The current process is confused.   For example, I currently plan on
> trying to remember to ask Linus to revert the MIPS seccomp stuff or
> fix it sometime around -rc6 if the patch hasn't landed, but this
> sucks.
> 
> I think that the process could be improved.  I think that there are
> people who are willing to spend time to read API docs and thinking
> about these kinds of issues.  (I am, and Michael Kerrisk seems to do a
> fair amount of it.)

We do have linux-api, which should be cc:ed for new api additions.  But
it usually isn't :(