public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin LaHaise <bcrl@kvack.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Greg KH <gregkh@suse.de>, Nicholas Miell <nmiell@comcast.net>,
	Greg KH <greg@kroah.com>, "Theodore Ts'o" <tytso@mit.edu>,
	Linus Torvalds <torvalds@osdl.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: Sun, 5 Mar 2006 19:39:33 -0500	[thread overview]
Message-ID: <20060306003933.GE20768@kvack.org> (raw)
In-Reply-To: <m1y7zoa0sf.fsf@ebiederm.dsl.xmission.com>

On Sun, Mar 05, 2006 at 05:12:48PM -0700, Eric W. Biederman wrote:
> Yes.  But it does sure stick out like a sore thumb in a patch or when
> you try to use it.  Especially if you do something evil like require
> user space to pass in a hash of the kernel code implementing the
> interface.  So even the smallest changes of the implementation break
> user space.

I thought the decree / consensus was that You Can't Do That.  Yes, some 
people want to, but that doesn't mean we should let them.

> I don't know all of the answers.  But if we are going to document something
> is half backed, let have the code behave like the interface is half backed
> and at least try to keep it out of the hands of most applications.

Why should it be merged into base then?  If it's in the mainstream kernel, 
it needs to be reasonably solid (which has always been a precondition for 
merging patches, aiui).

> To a large extent I agree that we should have fully backed interfaces in
> the stable kernel.  Is that always possible?  How often do things not show
> up until they are being used in the real world?  Is it possible to
> find those things out in experimental branches?

There's a big difference between those interfaces that have had a decent 
amount of thought put into them and those which have not.  Take ext2, 
which is a good example as it can still mount a filesystem made back in 
the early '90s today, yet it has undergone a huge amount of change.  What 
was the secret?  The superblock has a few flags for compatible and 
incompatible features.

API design is not rocket science, it just requires effort.  So long as we 
keep beating the drums about how important this is, people will learn and 
we will get better at catching these issues during review.

		-ben
-- 
"Time is of no importance, Mr. President, only life is important."
Don't Email: <dont@kvack.org>.

  reply	other threads:[~2006-03-06  0:44 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
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 [this message]
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=20060306003933.GE20768@kvack.org \
    --to=bcrl@kvack.org \
    --cc=akpm@osdl.org \
    --cc=davej@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=greg@kroah.com \
    --cc=gregkh@suse.de \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nmiell@comcast.net \
    --cc=perex@suse.cz \
    --cc=torvalds@osdl.org \
    --cc=tytso@mit.edu \
    /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