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

[josh@joshtriplett.org]

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.
[...]
> 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.)
> 
> I would like to discuss what we could change to make this work better
> in the future.  In an ideal world, I would like to see every core API
> change come with documentation, tests (possibly simple ones), and a
> post, with acks, to a list that covers just API changes.  This might
> be tough, but it could add a lot of value.
> 
> I've occasionally thought that API docs should live in the kernel tree
> in some reasonably well organized place so that patch sets can include
> doc patches.  I realize that this is contentious.
> 
> I'm sure that other people have other suggestions here.
> 
> --Andy
> 
> P.S.  I'm not on the invitation nominee list, so if people like this
> topic, I'd appreciate a nomination :)

I'm interested in this topic, and I'll second that nomination.  I'd
like to partipate in this discussion.

We need to have better processes for vetting new syscalls and ABIs far
more carefully than we currently do.  Right now, we require benchmarks
for any claimed performance increase; it's almost a given that if you
post an optimization without including benchmarks in the commit message,
it'll get rejected with a request to come back with numbers.  We need
similar standards for new syscalls or other userspace ABIs: come back
with test programs, test coverage information, etc.

- Josh Triplett