public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin LaHaise <bcrl@kvack.org>
To: Greg KH <gregkh@suse.de>
Cc: Greg KH <greg@kroah.com>,
	linux-kernel@vger.kernel.org, torvalds@osdl.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: Mon, 27 Feb 2006 15:01:07 -0500	[thread overview]
Message-ID: <20060227200107.GA14011@kvack.org> (raw)
In-Reply-To: <20060227194623.GC9991@suse.de>

On Mon, Feb 27, 2006 at 11:46:23AM -0800, Greg KH wrote:
> Then I suggest you work with the ALSA developers to come up with such a
> "stable" api that never changes.  They have been working at this for a
> number of years, if it was a "simple" problem, it would have been done
> already...

That depends on how it's being approached.  Writing an ABI takes effort, 
while it tends to be easier to simply write new code.

> Anyway, netlink is in the same category, with a backing userspace
> library tie :)
> 
> And, I have nothing against shipping userspace libraries with the kernel
> like this, if people think that's the easiest way to do it.  But even
> then, the raw interface is still "private" and you need to use the
> library to access it properly.

That's a lot easier if it gets installed with the kernel version as part of 
the path.  That might need some hacking in the dynamic linker.  Before going 
that far, it should really be a question of putting the ABI and necessary 
extensions under a microscope to see how much stability in an ABI is 
possible.  Perhaps we've been too lax in reviewing extensions to the kernel's 
ABI, resulting in things getting to the point where it now needs to be a 
more explicit part of the review process.

Half the problem is that the bits that actually form an ABI tend to be 
spread over random .c source files, include/asm and include/linux, so 
catching a change is rather difficult even for experienced reviewers.  It 
might make sense to start splitting out the structure definitions into an 
include/abi/ structure to make changes easier to spot.  It'll be a lot of 
work, but along the lines of the whole ioctl mess the end result will be 
an easier system for users to cope with (which is the main concern in 
maintaining an ABI -- making needless updates necessary for users and 
software authors is something I feel we should try to avoid).

		-ben
-- 
"Ladies and gentlemen, I'm sorry to interrupt, but the police are here 
and they've asked us to stop the party."  Don't Email: <dont@kvack.org>.

  reply	other threads:[~2006-02-27 20:06 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 [this message]
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
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=20060227200107.GA14011@kvack.org \
    --to=bcrl@kvack.org \
    --cc=akpm@osdl.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