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>.
next prev parent 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