Re: Recent changes to sysctl.h breaks glibc

[ebiederm@xmission.com (Eric W. Biederman)]

"H. Peter Anvin" <hpa@zytor.com> writes:

> Eric W. Biederman wrote:
> > 
> > ABI changes or ABI additions?
> > 
> > If the ABI is not fixed that is a bug.  Admittedly some interfaces
> > in the development kernel are still under development and so have not
> > stabilized on an ABI but that is a different issue.
> > 
> 
> 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 _\bB_\bU_\bG_\bS.
Yes _\bb_\bu_\bg_\bs happen but they are still _\bb_\bu_\bg_\bs.

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 _\bb_\bu_\bg.

> >>ABI headers is the only realistic solution.  We
> >>can't realistically get real ABI headers for 2.5, so please don't just
> >>break things randomly until then.
> > 
> > As the ABI remains fixed I remain unconvinced.  Multiple implementations
> > against the same ABI should be possible.  The real question which is the
> > more scalable way to do the code.
> 
> The ABI doesn't remain fixed.  Like everything else it evolves.

I meant to say the existing subset of the ABI, remains fixed.
Evolution by accretion is fine.

> > What I find truly puzzling is that after years glibc still needs
> > kernel headers at all.
> 
> What I find truly puzzling is that obviously intelligent people like
> yourself still seem to think that ABIs remain fixed.

Simply because if the existing subset of an ABI does not remain fixed
it is a _\bb_\bu_\bg.  Only once in a blue moon is there a chance for
an incompatible change, like when switching to x86-64.

And given my experiences running old a.out binaries Linux does a pretty good
job at this.  And I am not willing to admit that changes that
break backwards compatibility (except for applications that depended
on implementation bugs) are anything except bugs.  That would only
encourage changes that should not happen.

I do agree however that the ABI should be better documented.  And that
being able to automatically generate headers from the official
documentation would be advantageous.  With good documentation it
should actually be harder to change an ABI because what the old ABI
was will be clearer.

And I do agree that if the kernel builds with headers automatically
generated from the official documentation.  Then it will be easy
to guarantee they are in sync.

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.

Eric