kernel headers question.

Ben Scott dragonhawk at gmail.com
Mon Aug 21 09:20:01 EDT 2006


On 8/19/06, Steven W. Orr <steveo at syslang.net> wrote:
> It seems to me that we stopped using kernel headers a *long* time
> ago, but I could be wrong.

  One of the consistent losses in Linux is the refusal of the kernel
people to provide a standard userland interface.  They say we
shouldn't use the kernel's own headers, but don't provide an
alternative.

  So, in a sense, there's no "right" way to do this.  Some people have
provided "sanitized" kernel headers.  Distributions generally do the
same.  I'm not sure what that gets us.

  Up to and through the 2.4 series, there was a vague promise that the
kernel-to-user runtime interface wouldn't change in
backward-incompatible ways within x.y revisions (e.g., a user program
built against kernel 2.4.7 would run against kernel 2.4.11).

  I believe that went out the window with 2.6.  I think we're just
supposed to pray things work.  :-(

  I recently had the dismal experience of trying to build the LTSP
Build Environment on CentOS 4.3.  It kept puking due to kernel header
issues.  I couldn't get it work, and the little feedback I got from
the community was that it's a crap shoot for everybody.

  It's enough to make one want to try BSD....

> I'm hoping this is doable
> because I'm hard pressed to understand what things I would need to
> worry about in userspace that would be kernel specific.

  Anything that makes a system call is potentially effected by kernel changes.

  As a contrived example, if the system call number for write(2) is 4
in the current release, but then changes to 5 in the next kernel
release, and I don't update my userland, things are going to get
interesting.  A less contrived example would be when the kernel
changed the iptables interface, so you had to update the iptables
tools to get them to do anything more than segfault.

  In theory, the user-to-kernel interface is kept well isolated within
glibc, so if the kernel changes, one only needs to update glibc.  See
above about iptables.  And this doesn't help you any, since you are
actually building the C library.

-- Ben



More information about the gnhlug-discuss mailing list