From: "Theodore Ts'o" <tytso@mit.edu>
To: Greg KH <greg@kroah.com>
Cc: Linus Torvalds <torvalds@osdl.org>, Greg KH <gregkh@suse.de>,
Benjamin LaHaise <bcrl@kvack.org>,
linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
davej@redhat.com, perex@suse.cz,
Kay Sievers <kay.sievers@vrfy.org>
Subject: Re: [RFC] Add kernel<->userspace ABI stability documentation
Date: Tue, 28 Feb 2006 01:32:07 -0500 [thread overview]
Message-ID: <20060228063207.GA12502@thunk.org> (raw)
In-Reply-To: <20060227234525.GA21694@suse.de>
On Mon, Feb 27, 2006 at 03:45:25PM -0800, Greg KH wrote:
> > So I just don't see any upsides to documenting anything private or
> > unstable. I see only downsides: it's an excuse to hide behind for
> > developers.
>
> So should we just not even document anything we consider "unstable"?
> The first trys at things are usually really wrong, and that only can be
> detected after we've tried it out for a while and have a few serious
> users. Should we brand anything new as "testing" if the developer feels
> it is ready to go?
How about "we don't let anything into mainline that we consider
'unstable' from an interface point of view"?
There seems to be a fetish going on today that everything possible
should be mindlessly pushed out into userspace regardless of whether
or not it makes sense. What folks don't seem to understand is that
there is a tradeoff between implementational complexity (in terms of
lines of code in /usr/src/linux) and interface complexity (see Rusty's
talk about designing good interfaces and how hard that can be).
If we're not sure we can get the interface right, then maybe it's a
sign it needs to stay in -mm longer, or maybe we were trying to push
the wrong thing out into userspace. If the interface isn't easy to
understand, and we aren't confident that we can promise to never
change it once we put it out there (although of course we can always
add additional interfaces as we add new features), then maybe the
mistake was in trying to create the interface in the first place.
Don't get me wrong; I'm a big fan of pushing policy out of the kernel;
but only if the interface that we use to expose the kernel
functionality has been very carefully designed.
Another alternative, as a few people including myself have noted, is to
shipping that part of the userspace with the kernel sources, so that
it is part of the kernel sources from a release management point of
view, even if it lives in userspace.
- Ted
next prev parent reply other threads:[~2006-02-28 6:32 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-27 19:01 [RFC] Add kernel<->userspace ABI stability documentation Greg KH
2006-02-27 19:08 ` Arjan van de Ven
2006-02-27 19:11 ` Greg KH
2006-02-27 19:17 ` Arjan van de Ven
2006-02-27 19:22 ` Kumar Gala
2006-02-27 19:30 ` Greg KH
2006-02-27 19:31 ` Andi Kleen
2006-02-27 19:44 ` Greg KH
2006-03-01 13:53 ` Lars Marowsky-Bree
2006-03-01 14:10 ` Gabor Gombas
2006-03-01 14:35 ` Jes Sorensen
2006-03-01 16:30 ` Lars Marowsky-Bree
2006-02-27 20:06 ` Jesper Juhl
2006-02-27 19:35 ` Diego Calleja
2006-02-27 19:49 ` Greg KH
2006-02-27 19:57 ` Diego Calleja
2006-02-27 20:00 ` Greg KH
2006-02-27 20:13 ` Diego Calleja
2006-02-28 0:26 ` Greg KH
2006-02-27 19:36 ` Benjamin LaHaise
2006-02-27 19:46 ` Greg KH
2006-02-27 20:01 ` Benjamin LaHaise
2006-02-27 20:13 ` Greg KH
2006-02-27 20:22 ` John W. Linville
2006-02-27 22:00 ` Greg KH
2006-02-27 20:10 ` Arjan van de Ven
2006-02-27 22:58 ` Olivier Galibert
2006-02-27 20:20 ` Linus Torvalds
2006-02-27 21:04 ` Al Viro
2006-02-27 23:33 ` Nicholas Miell
2006-02-27 23:45 ` Greg KH
2006-02-28 1:52 ` Jason Lunz
2006-02-28 6:32 ` Theodore Ts'o [this message]
2006-02-28 6:41 ` Dave Jones
2006-03-01 0:34 ` Greg KH
2006-03-01 1:17 ` Nicholas Miell
2006-03-02 4:24 ` Greg KH
2006-03-05 16:17 ` Eric W. Biederman
2006-03-05 23:23 ` Benjamin LaHaise
2006-03-06 0:12 ` Eric W. Biederman
2006-03-06 0:39 ` Benjamin LaHaise
2006-03-06 2:15 ` Eric W. Biederman
2006-03-07 3:56 ` Greg KH
2006-02-27 19:52 ` Alistair John Strachan
2006-02-27 19:57 ` Greg KH
2006-02-27 20:05 ` Alistair John Strachan
2006-02-27 20:12 ` Greg KH
2006-02-27 20:15 ` Greg KH
2006-02-27 22:56 ` Olivier Galibert
2006-02-28 0:11 ` Greg KH
2006-02-27 20:01 ` Jesper Juhl
2006-03-01 0:21 ` Greg KH
2006-02-28 11:39 ` Nikita Danilov
2006-03-01 0:23 ` Greg KH
2006-03-01 7:27 ` Arjan van de Ven
2006-03-01 20:56 ` Greg KH
-- strict thread matches above, loose matches on Subject: below --
2006-03-07 14:44 Al Boldi
2006-03-07 15:21 ` Josh Boyer
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=20060228063207.GA12502@thunk.org \
--to=tytso@mit.edu \
--cc=akpm@osdl.org \
--cc=bcrl@kvack.org \
--cc=davej@redhat.com \
--cc=greg@kroah.com \
--cc=gregkh@suse.de \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=perex@suse.cz \
--cc=torvalds@osdl.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