Re: [RFC] Add kernel<->userspace ABI stability documentation
- From: Nicholas Miell <nmiell@xxxxxxxxxxx>
- Date: Tue, 28 Feb 2006 17:17:49 -0800
On Tue, 2006-02-28 at 16:34 -0800, Greg KH wrote:
On Tue, Feb 28, 2006 at 01:32:07AM -0500, Theodore Ts'o wrote:
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"?
In a perfect world, where we are all kick-ass programmers and never get
anything wrong and can always anticipate exactly how people will use the
interfaces we create, sure we could say this.
But until then, there's no way this can happen :)
For example, look at all of the gyrations that the sys_futex call went
through. It took people really using the thing before the final version
of how it would work could be added.
And another example, /proc. How many times over the past 15 years have
we had to upgrade the procps package to handle the addition or change of
one thing or another? We evolve over time to handle the issues that
come up with different architectures and needs. That's what makes Linux
so great.
This is a really bad example.
All the /proc related contortions are a direct result of the fact that
the multitudes of /proc "formats" are completely undocumented,
non-extensible, and largely unintended for programmatic usage[1]. (/sys
was supposed to solve some of these things, but it seems to be going the
same route, unfortunately.)
Honestly, despite what the ASCII fetish crowd[2] may say, Solaris got it
right by just exporting C structs. The parsing is certainly a hell of a
lot easier when you're dealing with actual C datatypes instead of
character strings and people hacking on /proc are probably less likely
to make ABI breaking changes when they're dealing with a struct instead
of a sprintf statement.
[1] Where's my EBNF?
[2] "But ASCII is easily manipulated by shell tools!!!!"
Well, then write a very small C program that spits out ASCII and stick
it in procps.
--
Nicholas Miell <nmiell@xxxxxxxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- References:
- Prev by Date: Re: Max mem space per process under 2.6.13-15.7-smp
- Next by Date: Re: [patch] i386: port ATI timer fix from x86_64 to i386
- Previous by thread: Re: [RFC] Add kernel<->userspace ABI stability documentation
- Next by thread: Re: [RFC] Add kernel<->userspace ABI stability documentation
- Index(es):
Relevant Pages
|
