Inclusion of Linux headers in current glibc

[Andreas Jaeger]

I've made an analysis of the currently used Linux kernel headers by
the current glibc development version (I hope I didn't miss any
headers, I did this semi-automatic).

glibc includes directly the following 26 linux headers:
linux/a.out.h
linux/atalk.h
linux/errno.h
linux/if_ether.h
linux/if_fddi.h
linux/if_slip.h
linux/if_tr.h
linux/igmp.h
linux/kd.h
linux/kernel.h
linux/limits.h
linux/nfs.h
linux/param.h
linux/pci.h
linux/posix_types.h
linux/ppp-comp.h
linux/ppp_defs.h
linux/prctl.h
linux/sockios.h
linux/soundcard.h
linux/sysctl.h
linux/ultrasound.h
linux/user.h
linux/version.h
linux/vt.h

and the following ASM files:
included from Alpha specific files (7 files):
asm/elf.h
asm/fpu.h
asm/gentrap.h
asm/ioctls.h
asm/page.h
asm/pal.h
asm/reg.h

included from Sparc (sparc subdir) specific files (1 file):
asm/traps.h

included from Sparc32 specific files (2 files):
asm/errno.h
asm/unistd.h

included from Sparc64 specific files (3 files):
asm/asi.h
asm/errno.h
asm/unistd.h

included from ia64 specific files (8 files):
asm/elf.h
asm/errno.h
asm/fpu.h
asm/page.h
asm/resource.h
asm/signal.h
asm/system.h
asm/unistd.h

included from Arm specific files (2 files):
asm/page.h
asm/ptrace.h

included from i386 specific files (1 file):
asm/vm86.h

included from MIPS specific files (6 files):
asm/cachectl.h
asm/elf.h
asm/ioctls.h
asm/socket.h
asm/sysmips.h
asm/unistd.h

included from PowerPC specific files (2 files):
asm/page.h
asm/ptrace.h

included from SH specific files (1 file):
asm/ptrace.h

included from Generic files  (6 files):
asm/elf.h
asm/ioctls.h
asm/sigcontext.h
asm/socket.h
asm/types.h
asm/unistd.h

Checking all the *.d files on i686 shows that only these 25 headers are
needed for compiling (!) glibc:
asm/a.out.h
asm/errno.h (included via another header)
asm/ioctl.h  (included via another header)
asm/ioctls.h  (included via another header)
asm/page.h  (included via another header)
asm/param.h  (included via another header)
asm/posix_types.h  (included via another header)
asm/sigcontext.h  (included via another header)
asm/socket.h 
asm/sockios.h  (included via another header)
asm/types.h
asm/unistd.h
linux/a.out.h
linux/atalk.h
linux/errno.h
linux/if_ether.h
linux/kernel.h
linux/limits.h
linux/list.h  (included via another header)
linux/nfs.h
linux/param.h
linux/posix_types.h
linux/stddef.h  (included via another header)
linux/sunrpc/msg_prot.h  (included via another header)
linux/sysctl.h


The question is now what we should do, I don't think I've need to
rephrase the problems we have with the inclusion of kernel headers
(even if every release of glibc includes less headers).  I see the
following suggestions and I might consider doing the work if we come
(but wouldn't mind if somebody else does it;-) to a consensus:
* Leave everything as it is (I don't think this is feasible long
  time)
* Include less kernel headers (that's what we're doing in the moment -
  but we are normally to late since a header is removed if it rises a
  problem).
* Include all needed kernel headers in the glibc archive:
  + No more compatibility problems, no /usr/include/linux or
    /usr/include/asm needed by glibc since glibc would have a copy of
    kernel headers somewhere
  + We could remove some problems from the kernel headers.
  - Duplicate definitions means duplicate work - and this would mean
    that we have more headers to look at whenever Linus releases a new
    kernel.
* Copy at glibc build time all needed headers (or just all headers)
  from the kernel to a private place:
  + Less maintaince and duplication 
  - We need to find a way to know which headers are really needed
    which isn't that easy since headers include other headers.
  + If kernel header are changed, user level programs will not notice
    this.
  - If glibc is rebuild, it might give conflicts with the kernel
    headers as it already does.

We also should discuss (thanks Jakub for mentioning this) if we
consider only changing :
* those files we install in /usr/include
* or all glibc files

What other solutions do you see?  What shall we do?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de