From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id B617A875 for ; Tue, 6 May 2014 17:58:46 +0000 (UTC) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 464BB201A2 for ; Tue, 6 May 2014 17:58:46 +0000 (UTC) Date: Tue, 6 May 2014 10:58:42 -0700 From: josh@joshtriplett.org To: Andy Lutomirski Message-ID: <20140506175842.GF20776@cloud> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [CORE TOPIC] Reviewing new API/ABI List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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