"H. Peter Anvin" <hpa@zytor.com> writes:
> 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.
It is correct by definition, the existing part of an ABI may not change.
> 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.
Sure you can add new functionality in a defined way. You can add to
the ABI. You may not modify an existing definition. But that has
no implications for existing working code.
> > 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.
But since the older interface still remains you don't have to change
klibc, uclibc, dietlibc, and whatever else does not care. Making
it easy to change an existing ABI is simply wrong.
If you were to increment the syscall numbers by one no amount of automation
in the world would make that a kernel that would be usable on a production
box. The only way it could even work is if you were to declare that
kernel uses a new ABI.
> 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.
If things must be maintained in concert it is a bug.
With a fixed ABI people take advantage of new features as they
care for them. And in general to use new features requires new code.
If people are adding and changing ioctls/sysctls/prctls left and right,
and that is what is causing the maintenance problem, then that is the
problem. And that is where the problem needs to be reigned in at.
> 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.
Agreed.
Calling it documentation simply makes it clear what the headers are,
and suggest that the machine readable for does not need to be C source
code.
Eric
-
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