From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [CORE TOPIC] Reviewing new API/ABI
Date: Tue, 6 May 2014 22:10:17 +0200 [thread overview]
Message-ID: <CAKMK7uHT0S0fGnaf2CesCJcG--pZxd=0xtk08KwAuGAj53-RqA@mail.gmail.com> (raw)
In-Reply-To: <1399404095.4218.51.camel@jlt4.sipsolutions.net>
On Tue, May 6, 2014 at 9:21 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2014-05-06 at 10:58 -0700, josh@joshtriplett.org wrote:
>
>> We need to have better processes for vetting new syscalls and ABIs far
>> more carefully than we currently do.
>
> How far would you want to take this? New syscalls is one thing, but
> there are frequently additions to "subsystem APIs", e.g. in networking,
> that aren't really syscalls but part of netlink etc. Trying to vet all
> of that might very well end up just overwhelming the process, but on the
> other hand it's still something that probably should be done in some
> form.
drm drivers add massive amounts of per-driver ioctls/sysfs files/...
and of course we've done all the usual (and a lot of the unusual) api
design mistakes. For i915 I've got fed up with all that and we've
switched to a fairly strict regime:
1. Patches that add new abi need to have full userspace ready before
the kernel side gets merged. Usually that means an (open source)
implementation of the OpenGL feature for that feature in mesa,
including all the functionality tests mesa requires (which are again
open source in piglit). New interfaces without fully validated and
working userspace parts get rejected.
2. I also require detailed testcases of all the corner-cases (reserved
bits/fields, signal handling, corener-cases/interactions with other
interfaces, overflow/array bounds issues, ...). Those low-level tests
are in intel-gpu-tools. I also have a lenghty blog with all the
mistakes we've done thus far wrt userspace interface design and what
kind of test coverage I expect:
http://blog.ffwll.ch/2013/11/botching-up-ioctls.html
3. Patches which require a testcase should have a Testcase: tag to
make sure both pieces (kernel patch + testcase) are linked together.
They usually also get reviewed in tandem by the same person.
I've made it very clear (and enforced this a bunch of times already)
that patches which don't follow this will be rejected. In my
experience (we've been doing this since about a year or so) this takes
care of the abi design fun completely.
I guess in a year or so I'll also add
4. Create/update the relevant manpage.
But currently we don't yet have that part set up (and also higher
priorities for documentation elsewhere in the stack).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-05-06 20:10 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-06 17:45 Andy Lutomirski
2014-05-06 17:58 ` josh
2014-05-06 19:12 ` Shuah Khan
2014-05-06 19:16 ` Andy Lutomirski
2014-05-06 19:37 ` Shuah Khan
2014-05-06 19:21 ` Johannes Berg
2014-05-06 19:43 ` Andy Lutomirski
2014-05-06 19:48 ` Johannes Berg
2014-05-06 19:51 ` Andy Lutomirski
2014-05-06 19:45 ` josh
2014-05-06 20:10 ` Daniel Vetter [this message]
2014-05-06 20:13 ` Andy Lutomirski
2014-05-07 10:12 ` Laurent Pinchart
2014-05-07 12:36 ` Daniel Vetter
2014-05-07 13:30 ` Laurent Pinchart
2014-05-07 13:50 ` Hans Verkuil
2014-05-12 14:15 ` Wolfram Sang
2014-05-07 17:48 ` Michael Kerrisk (man-pages)
2014-05-06 19:00 ` Greg KH
2014-05-06 20:07 ` Steven Rostedt
2014-05-06 20:34 ` Josh Triplett
2014-05-06 20:42 ` Steven Rostedt
2014-05-06 21:00 ` josh
2014-05-07 11:48 ` Jiri Kosina
2014-05-08 6:35 ` Li Zefan
2014-05-12 6:37 ` Jiri Kosina
2014-05-07 6:27 ` Michael Kerrisk (man-pages)
2014-05-06 19:57 ` Dan Carpenter
2014-05-08 18:15 ` Randy Dunlap
2014-05-09 11:33 ` Jeff Layton
2014-05-09 11:50 ` Michael Kerrisk (man-pages)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKMK7uHT0S0fGnaf2CesCJcG--pZxd=0xtk08KwAuGAj53-RqA@mail.gmail.com' \
--to=daniel.vetter@ffwll.ch \
--cc=johannes@sipsolutions.net \
--cc=ksummit-discuss@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox