Eric W. Biederman wrote:
>>
>>ABI fixes and ABI additions, as well as outright ABI changes (yes they
>>suck, but they happen.)
>
> And ABI changes from the ABI exposed by a stable kernel are _B_U_G_S.
> Yes _b_u_g_s happen but they are still _b_u_g_s.
>
> It is legal to stop supporting an interface but changing the interface
> in such a way that you must know the version of the kernel you are
> running on is a _b_u_g.
>
Yes. And guess what? Bugs happen. Sometimes you can't fix them either
because the "new" usage has gotten established. However, that's not the
point.
Your message assumes that the ABI remains fixed. This is totally and
utterly and undeniably WRONG. There are rules for how it may evolve,
but it very much does evolve. No amount of handwaving or putting
underscores in weird places will change that.
>
> But there is no reason not to write documentation today about what the
> kernel interfaces are and convert glibc and the kernel later when
> it is convenient to their development cycles.
>
> What I do not is see the necessity of using automation to follow the
> documentation.
>
Otherwise you have three places to manually make your changes (usually
more) -- the documentation, the kernel, and glibc... and really you also
have klibc, uclibc, dietlibc, and God knows what else.
Automation is the way to maintain these together and in concert, to
avoid your "B_ U_ G_ S_." This isn't just a Good Thing, this is the
only sane possibility.
Does that mean C source code is the only possible format? It most
certainly *doesn't* -- in fact one could argue it's not even a very good
format -- as long as C source code is one of the possible productions.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri May 23 2003 - 22:00:37 EST