Re: Header files and the kernel ABI

[dank@kegel.com]

Oliver Xymoron <oxymoron@waste.org> wrote:
> 
> On Thu, 25 Jul 2002, Erik Andersen wrote:
> 
> > On Thu Jul 25, 2002 at 09:31:23AM -0700, H. Peter Anvin wrote:
> > > Oliver Xymoron wrote:
> > > >
> > > >Ideally, the ABI layer would be maintained and packaged separately from
> > > >both the kernel and glibc to avoid gratuitous changes from either side.
> > >
> > > I disagree.  The ABI is a product of the kernel and should be attached
> > > to it.  It is *not* a product of glibc -- glibc is a consumer of it, as
> > > are any other libcs.
> >
> > Agreed.  I maintain a libc and I certainly do not want to
> > have to maintain the kernel ABI of the day headers.  That
> > is clearly a job for the kernel.
> 
> The idea of maintaining them separately is that people won't be able to
> touch the ABI without explicitly going through a gatekeeper whose job is
> to minimize breakage. Linus usually catches ABI changes but not always.
> 
> I explicitly did _not_ suggest making it the job of libc maintainers. And
> the whole point of the exercise is to avoid ABI of the day anyway. The ABI
> should change less frequently than the kernel or libc. It's more analogous
> to something like modutils.

IMHO it should live with the kernel, at least for now.  
The ABI .h files can live in a walled-off area that stays as stable as possible.
Anyone building glibc should be able to grab the ABI .h files from a
recent linux kernel source tarball without much effort.  (Maybe we'd
add a 'install headers_install' make target to install the ABI .h files
to make it obvious how to get them.)

Imagine what would happen if the base ABI .h files were maintained 
as part of a future Linux Standard Base, with the kernel only maintaining
.h files for extensions to the base ABI.  You'd need to install the ABI .h 
files before you could build the kernel!  That might be the right way to
go, but let's not propose it until the ABI .h files exist and are useful.

- Dan